[ih] BufferBloat: What's Wrong with the Internet?

[Dave Taht]

On Mon, Aug 29, 2022 at 8:32 AM the keyboard of geoff goodfellow via
Internet-history <internet-history at elists.isoc.org> wrote:
>
> *A discussion with Vint Cerf, Van Jacobson, Nick Weaver, and Jim Gettys*
>
> December 7, 2011
> Volume 9, issue 12
>
> Note: Be sure to read the companion article to this one, Bufferbloat: Dark
> Buffers in the Internet <https://dl.acm.org/detail.cfm?id=2071893> (
> https://cacm.acm.org/magazines/2012/1/144810-bufferbloat/fulltext)*. - Ed.*
>
> *Internet delays are now as common as they are maddening. That means they
> end up affecting system engineers just like all the rest of us. And when
> system engineers get irritated, they often go looking for what's at the
> root of the problem. Take Jim Gettys, for example. His slow home network
> had repeatedly proved to be the source of considerable frustration, so he
> set out to determine what was wrong, and he even coined a term for what he
> found: bufferbloat.*
>
> *Bufferbloat refers to excess buffering inside a network, resulting in high
> latency and reduced throughput. Some buffering is needed; it provides space
> to queue packets waiting for transmission, thus minimizing data loss. In
> the past, the high cost of memory kept buffers fairly small, so they filled
> quickly and packets began to drop shortly after the link became saturated,
> signaling to the communications protocol the presence of congestion and
> thus the need for compensating adjustments.*
>
> *Because memory now is significantly cheaper than it used to be, buffering
> has been overdone in all manner of network devices, without consideration
> for the consequences. Manufacturers have reflexively acted to prevent any
> and all packet loss and, by doing so, have inadvertently defeated a
> critical TCP congestion-detection mechanism, with the result being worsened
> congestion and increased latency.*
>
> *Now that the problem has been diagnosed, people are working feverishly to
> fix it. This case study considers the extent of the bufferbloat problem and
> its potential implications. Working to steer the discussion is Vint Cerf,
> popularly known as one of the "fathers of the Internet." As the co-designer
> of the TCP/IP protocols, Cerf did indeed play a key role in developing the
> Internet and related packet data and security technologies while at
> Stanford University from 1972-1976 and with DARPA (the U.S. Department of
> Defense's Advanced Research Projects Agency) from 1976-1982. He currently
> serves as Google's chief Internet evangelist.*
>
> *Van Jacobson, presently a research fellow at PARC where he leads the
> networking research program, is also central to this discussion. Considered
> one of the world's leading authorities on TCP, he helped develop the RED
> (random early detection) queue management algorithm that has been widely
> credited with allowing the Internet to grow and meet ever-increasing
> throughput demands over the years. Prior to joining PARC, Jacobson was a
> chief scientist at Cisco Systems and later at Packet Design Networks.*
>
> *Also participating is Nick Weaver, a researcher at ICSI (International
> Computer Science Institute in Berkeley where he was part of the team that
> developed Netalyzr, a tool that analyzes network connections and has been
> instrumental in detecting bufferbloat and measuring its impact across the
> Internet.*
>
> *Rounding out the discussion is Gettys, who edited the HTTP/1.1
> specification and was a co-designer of the X Window System. He now is a
> member of the technical staff at Alcatel-Lucent Bell Labs, where he focuses
> on systems design and engineering, protocol design, and free software
> development...*
>
> [...]
>
> https://queue.acm.org/detail.cfm?id=2076798
>
> also at
>
> https://cacm.acm.org/magazines/2012/2/145415-bufferbloat-whats-wrong-with-the-internet/fulltext

Yes, 11 years after this, the internet - even and especially on new
tech like 5G and Starlink, is still horrifically overbuffered. Given
how rapidly "slow start" had rolled out in the 80s, I would have
thought that the 300 or so lines of code in the fq_codel or pie
algorithms would have rolled out more universally than they have. I
figured we'd be done in 7 years, but it looks to me to be another 14,
if ever.

There's been a LOT of progress though (see my .sig), and most recently
both ookla and speedtest.net have added tests for latency under up or
down load. Those bloated results keep popping up in article after
article online with people complaining about their "bandwidth", with
few to none even noticing those numbers point at the bloat problem. I
yearn for a very public experiment, like this one, where in a flash,
everyone suddenly realizes where the real problem was.

https://www.youtube.com/watch?v=6Rwcbsn19c0



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC