Us bufferbloat folk have been putting together a response to the FCC's
NOI (notice of inquiry) asking for feedback as to increasing the
broadband speeds beyond 100/20 Mbit.
"Calls for further bandwidth increases are analogous to calling for
cars to have top speeds of 100, 200, or 500 miles per hour. Without
calling also for better airbags, bumpers, brakes, or steering wheels,
(or roads designed to minimize travel delay), these initiatives will
fail (and are failing) to meet the needs of present and future users
of the internet."
Comments (and cites) welcomed also! The text is still somewhat in flux...
Not sure we need the FCC telling us how to build products or run networks. Seat belts are life-or-death, but bufferbloat is rarely fatal Let it be a point of differentiation.
If you want money from the government to subsidize your network, you'll follow their rules...
It is the misguided focus on too many too simple things from the
regulator and Congress, without even understanding what a packet is,
and enormous subsidies for things that don't matter, and great
mis-understanding of the things that do, that bothers me the most.
Anyway, for 14 years, I have been trying to get bufferbloat fixed,
universally, and great progress is being made. I felt that with one
political push like this, it might begin to turn the tide. We are
accepting signatures on the FCC filing until 2PM EST today.
The FCC is currently posturing to feel relevant. While they’re in one of these modes, you’re not going to stop them, but you might be able to redirect them on a better path.
You start off with a decent thesis - beyond 100mbps there really isn't
any difference in capability, not for residential use. Just a
difference in how quickly some tasks complete. It's not like the
difference between 768kbps and 10 mbps where one does streaming video
and conferencing while the other does not.
But then you get lost in latency. Latency is important but it's only
one in a laundry list of things that make the difference between
quality and trash in Internet services.
* Packet loss.
* Service outages. I have a buddy whose phone line has been out for
days four times this year. His ILEC neither wants to maintain the
copper lines nor install fiber that deep in the woods, so they keep
doing mediocre repairs to the infrastructure that don't hold up.
* Incomplete connectivity (e.g. Cogent and IPv6).
Personally, I'd love to see rulemaking to the effect that only folks
with -open- peering policies are eligible for government funds and
contracts. But that's my pet peeve, like latency is yours. And if I
pitch that, it'll rightly be seen as a pet issue.
Yea I’d like to see mandated IPv6 if ISPs want government money, around here an IPv4 only ISP won a government contract a while back for res fiber deployment and the last I heard from an acquaintance I spoke to over there they are planning to stuff the entire city behind a /24 with no upcoming plans to enable v6 (but of course you can get your own IP if you pay more).
I’m not a conspiracy theorist but sometimes it feels like some smaller ISPs are intentionally not deploying v6 so they can get customers to upgrade to more expensive plans for the luxury of *checks notes* not getting rate limited.
Unfortunately from my experience it’s usually because the small local ISPs don’t have the resources to understand IPv6, and may be using equipment generations old that may not support IPv6. It’s the large ISPs that don’t want to do it because it would increase their operational costs and require upgrades to operational systems and they see no new revenue associated.
Honestly, how old is your equipment at this point to not support IPv6 at all or usably in the data plane and in-band parts of the control plane? I wouldn't think it's even commercially relevant anymore. Pretty much anything L3 with at least 10Gb ports probably has support for most things relevant to a small local ISP.
You might be missing some niceties, but even some new stuff is missing those. The big one I've seen is a nice way to handle DHCPv6-PD delegations without having to resort to using BGP to inject the routes (looking at you, Extreme SLX).
Us bufferbloat folk have been putting together a response to the FCC's
NOI (notice of inquiry) asking for feedback as to increasing the
broadband speeds beyond 100/20 Mbit.
The era of “buffer bloat” has passed. Buffer bloat is just about jitter, and jitter mitigation is just better now.
I don’t think jitter needs to be part of public policy.
Trying to put technical requirements like this into law and public policy is an extremely terrible idea. This letter should never be sent.
The regulatory agencies today don’t have the manpower or expertise to adequately enforce the more generic broadband deployment rules. What fantasy world exists where they have the manpower or expertise to monitor for and enforce something like this? Hell, there are constant , legitimate technical discussions between experts on HOW to properly monitor things just like this. We want to have someone at the FCC deciding what that should look like?
4.4 What the hell? The regulatory agencies should be allocating spectrum, and making sure it’s not used improperly with the rules of allocation. Making it work ‘better’ is OUR job in the technical community. Not an FCC rulemaker.
4.8 There are zero scenarios there should ever be regulatory rules about device software. In our space (non-ISP) , TONS of people run older versions of vendor code. Why? The shit DOESN’T WORK RIGHT YET and it causes other problems. You suggest that regulatory bodies be involved in dictating anything about this?
The bufferbloat work belongs in the technical area, full stop. Nowhere near regulatory / legal.
Again, these rules typically only relevant when you are taking government funding or the government is looking to allocate future funding. Providers who don’t take government funding are welcome to run their networks as they choose.
6rd works well enough, has been around long enough, and doesn't
require any significant equipment upgrades to implement. An ISP who
hasn't at least implemented that much is just being lazy.
I agree. But I do have a question: is there a Best Practices RFC for setting buffer sizes in the existing corpus? The Internet community has been pretty good at setting reasonable standards and recommendations, so a pointer to a BCP or RFC would go much farther to solve the bufferbloat problem, as I believe administrators would prefer the "suggestion" instead of ham-handed regulation.
But that's just me. I do know there has been academic research on the subject, but don't recall seeing the results published as a practical operational RFC.
(And this is very much on-topic for NANOG, as it is about encouraging our peers to implement effective operation in their networks, and in their connections with others.)
Let it be a point of differentiation.