sigs wanted for a response to the fcc's NOI for faster broadband speeds
Over here: https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4... 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... -- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
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. -- Tom On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
If you want money from the government to subsidize your network, you'll follow their rules... On Fri, Dec 1, 2023 at 12:39 PM Tom Mitchell <tmitchell@netelastic.com> wrote:
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.
-- Tom
On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
On Fri, Dec 1, 2023 at 12:46 PM Shane Ronan <shane@ronan-online.com> wrote:
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. https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
On Fri, Dec 1, 2023 at 12:39 PM Tom Mitchell <tmitchell@netelastic.com> wrote:
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.
-- Tom
On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
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. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Mitchell" <tmitchell@netelastic.com> To: "Dave Taht" <dave.taht@gmail.com> Cc: "NANOG" <nanog@nanog.org>, "NZNOG" <NZNOG@list.waikato.ac.nz>, "<ausnog@lists.ausnog.net>" <ausnog@lists.ausnog.net> Sent: Friday, December 1, 2023 11:38:10 AM Subject: Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds 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. -- Tom On Thu, Nov 30, 2023 at 4:56 PM Dave Taht < dave.taht@gmail.com > wrote: Over here: https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4... 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... -- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
bufferbloat is rarely fatal LOL! I know one person taht may disagree with that :) -mel On Dec 1, 2023, at 9:41 AM, Tom Mitchell <tmitchell@netelastic.com> wrote: 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. -- Tom On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com<mailto:dave.taht@gmail.com>> wrote: Over here: https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4... 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... -- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
On Fri, Dec 1, 2023 at 1:55 PM Mel Beckman <mel@beckman.org> wrote:
bufferbloat is rarely fatal
This task will put me in my grave, sooner rather than later!
LOL! I know one person taht may disagree with that :)
-mel
On Dec 1, 2023, at 9:41 AM, Tom Mitchell <tmitchell@netelastic.com> wrote:
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.
-- Tom
On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
As one beholden to USAC/FCC I have to agree with Shane... michael brooks Sr. Network Engineer Adams 12 Five Star Schools michael.brooks@adams12.org :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: "flying is learning how to throw yourself at the ground and miss" On Fri, Dec 1, 2023 at 10:39 AM Tom Mitchell <tmitchell@netelastic.com> wrote:
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.
-- Tom
On Thu, Nov 30, 2023 at 4:56 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4... <https://urldefense.com/v3/__https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit__;!!IR39LLzvxw!M_bC8YhyxVaDflZyWHjIqI3S_nFkGJi-hoTv9t_2pKc_5c68WnYm3nvy9SxIy0mdCEr2GVgtCcvNuGwxBWz84-A2Y2Ag$>
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab <https://urldefense.com/v3/__https://tinyurl.com/yurtlab__;!!IR39LLzvxw!M_bC8YhyxVaDflZyWHjIqI3S_nFkGJi-hoTv9t_2pKc_5c68WnYm3nvy9SxIy0mdCEr2GVgtCcvNuGwxBWz846BrgErs$> Dave Täht CSO, LibreQos
-- This is a staff email account managed by Adams 12 Five Star Schools. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.
On Thu, Nov 30, 2023 at 4:55 PM Dave Taht <dave.taht@gmail.com> wrote:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
Comments (and cites) welcomed also! The text is still somewhat in flux...
Hi Dave, 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. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
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. Sent from my iPhone
On Dec 1, 2023, at 15:41, William Herrin <bill@herrin.us> wrote:
On Thu, Nov 30, 2023 at 4:55 PM Dave Taht <dave.taht@gmail.com> wrote:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
Comments (and cites) welcomed also! The text is still somewhat in flux...
Hi Dave,
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
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. Shane On Fri, Dec 1, 2023 at 4:23 PM Daniel Marks via NANOG <nanog@nanog.org> wrote:
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.
Sent from my iPhone
On Dec 1, 2023, at 15:41, William Herrin <bill@herrin.us> wrote:
On Thu, Nov 30, 2023 at 4:55 PM Dave Taht <dave.taht@gmail.com> wrote:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
Comments (and cites) welcomed also! The text is still somewhat in
flux...
Hi Dave,
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On 12/1/23 16:45, Shane Ronan wrote:
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). -- Brandon Martin
On Fri, Dec 1, 2023 at 1:45 PM Shane Ronan <shane@ronan-online.com> wrote:
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.
Hi Shane, 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. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
Or has no engineer capable of configuring it, or support staff trained to handle the issues that will come up. There are many reasons why providers don’t support v6.
On Dec 1, 2023, at 11:20 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Dec 1, 2023 at 1:45 PM Shane Ronan <shane@ronan-online.com> wrote:
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.
Hi Shane,
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.
Regards, Bill Herrin
-- William Herrin bill@herrin.us https://bill.herrin.us/
On Fri, Dec 1, 2023 at 8:35 PM <sronan@ronan-online.com> wrote:
Or has no engineer capable of configuring it, or support staff trained to handle the issues that will come up.
Like I said: lazy. Training to deploy and support a minimalist 6rd deployment where customers who want it can optionally use it is not a challenging task. A man-week from zero to working. Maybe two. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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. Tom
On Fri, Dec 1, 2023 at 6:21 PM Tom Samplonius <tom@samplonius.org> wrote:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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 am really not sure what world you live in. Certainly the problem has got much better since 2010, but nearly every network I ever explore still has vast amounts of it. The global south, every coffee shop, and every hotel I have been in, all have major issues here. I make a habit of testing the conference wifi and posting results at every talk. The apartment complex I am staying in this week has a completely saturated backhaul and oversubscribed wifi, with tremendous amounts of delay and packet loss, where more constructive packet loss would help. Google docs is nearly unusable most of the day... and so it goes. I do hope the solutions for bloat continue to roll out globally and we cross this chasm in the next few years.
I don’t think jitter needs to be part of public policy.
Congress has mandated a report from the FCC every year about the state of the internet, which is what this attempt at a constructive policy change of focus was about.
Tom
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
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. On Thu, Nov 30, 2023 at 7:57 PM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
It would be better to keep the government out of it altogether, but that has little chance of happening. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Dave Taht" <dave.taht@gmail.com> Cc: "NANOG" <nanog@nanog.org>, "NZNOG" <NZNOG@list.waikato.ac.nz>, "<ausnog@lists.ausnog.net>" <ausnog@lists.ausnog.net> Sent: Friday, December 1, 2023 6:34:49 PM Subject: Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds 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. On Thu, Nov 30, 2023 at 7:57 PM Dave Taht < dave.taht@gmail.com > wrote: Over here: https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4... 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... -- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
On 12/1/23 5:27 PM, Mike Hammett wrote:
It would be better to keep the government out of it altogether, but that has little chance of happening.
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.)
On Sat, Dec 2, 2023 at 2:30 AM Stephen Satchell <list@satchell.net> wrote:
On 12/1/23 5:27 PM, Mike Hammett wrote:
It would be better to keep the government out of it altogether, but that has little chance of happening.
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.
I too! The IETF recommends universal AQM: see RFC7567. However, as a consensus document, it was impossible to get the group to agree to fair (flow) queuing also being deployed universally, (although it is discussed extensively) where I feel that that technology - breaking up bursts, making it possible for all flows to multiplex better to a destination, and isolating problematic flows - is more important than AQM. A lot of FQ is implicit - packet pacing from the hosts does it e2e, switches naturally multiplex from multiple ports, but anywhere it is not, explicitly having it helps in downshifting from one rate to another. A pure AQM tends to react late to bursts otherwise. "Flow Queuing", is a real advance over conventional fair queueing, IMHO. PIE has a delay target of 16ms, Codel 5ms - but these are targets that take a while to hit, absorbing bursts, and then draining the queue to a steady, smaller state gradually. I recommend VJ's talk on this highly: https://www.bufferbloat.net/projects/cerowrt/wiki/Bloat-videos/#van-jacobson... (he has also been heavily involved in BBR and so many other things) If all you have is a FIFO, I personally would recommend no more than 30ms in a byte fifo, if available. A packet fifo, limited thusly, might have issues with swallowing enough acks, but either way, with the advent of "packet pacing" from the hosts, some pretty good experimental evidence that 100ms is too much... (I can supply more links), and the rise of unclassified interactive traffic like webrtc with tighter delay constraints, I still lean strongly towards 30ms as the outside figure in most cases. Aside from incast traffic, you only need even this much buffering when a link is oversubscribed. Try not to do that, but test. We got back a lot of good data from the level3 outage showing that a lot of core seemed to have 250ms of buffering, or more. I can dig up that research. For more RFCs from the now closed IETF AQM working group, see: https://datatracker.ietf.org/group/aqm/documents/
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.
I too would like a practical operational RFC. It is becoming increasingly practical, but the big vendors are lagging behind on support for advanced FQ and AQM techniques. There has been some decent work in P4. In my case on problematic links I just slap CAKE in front of it on a whitebox. Example of the generally pleasing results here: https://blog.cerowrt.org/post/juniper/ (this blog also references the debate about the BDP in relation to the number of flows controversy) That blog also shows the degradation in tcp performance once buffers crack 250ms - a sea of retransmits with ever decreasing goodput. Cisco has AFD (approximate fair drop). I have zero reports from the field from those configuring it. I hear good things about Juniper's RED implementation but have not torn it apart, and few configure it that I know of. I would love it if more people slapped LibreQos on an oversubscribed link (it's good to well past 25Gbit and pushes cake to about 10Gbits/core destination), and observed what happened to user satisfaction, packet drops, RFC3168 ecn, and flow collisions in the 8 way set associative hash , and so on. We've produced some good tools for it, notably tcp sampling of the rtt, as well as nearly live "mice and elephants" plots from the 2002 paper on it.
(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.)
I too encourage everyone. -- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
What I've found missing were references to packet loss impact on performance. It seems to assume cable/fiber environments with little to no packet loss, while Wi-Fi and 3G/4G/5G are not like that. Rubens On Fri, Dec 1, 2023 at 7:23 AM Dave Taht <dave.taht@gmail.com> wrote:
Over here:
https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4...
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...
-- :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab Dave Täht CSO, LibreQos
On Sat, Dec 2, 2023 at 5:04 PM Rubens Kuhl <rubensk@gmail.com> wrote:
What I've found missing were references to packet loss impact on performance. It seems to assume cable/fiber environments with little to no packet loss, while Wi-Fi and 3G/4G/5G are not like that.
Wireless environments tend to do L2 retransmission, so they express packet loss as jitter (random change in latency) instead of actual loss. If you're seeing loss, it's generally on a wired segment. Regards, Bill Herrin -- William Herrin bill@herrin.us https://bill.herrin.us/
participants (14)
-
Brandon Martin -
Daniel Marks -
Dave Taht -
Mel Beckman -
michael brooks - ESC -
Mike Hammett -
Rubens Kuhl -
Shane Ronan -
sronan＠ronan-online.com -
Stephen Satchell -
Tom Beecher -
Tom Mitchell -
Tom Samplonius -
William Herrin