Re: [113attendees] Network Responsiveness at IETF meeting

[Stuart Cheshire <[e-mail]>]

I want to make it clear that my email yesterday was not intended as any criticism of the hardworking volunteers who run the IETF meeting networks or the generous companies that donate the equipment we use. Sincere thanks to both those groups.

The problem is that bufferbloat is everywhere, and we still have a limited selection of tools to detect bufferbloat, and limited awareness of those tools. Without routine use of bufferbloat detection tools, it is not at all surprising that bufferbloat remains a problem, even a decade after Jim Gettys identified the problem and coined the term “bufferbloat”.

What we experience is that sometimes network connections work well and our subjective experience using our computers and devices is that everything is “snappy” and fast. Other times everything is sluggish and slow, with no clear reason why. We can run an Internet speed test to see how many megabits of throughput we have, but that usually doesn’t tell us anything useful. What we’ve found is that above about 10 Mb/s there is little correlation between throughput rates and the experienced responsiveness of most day-to-day computing activities. If you have a 10 Gb/s Internet connection with a 1-second round trip time, then your once-a-year download of your operating system software update might be very fast, but for the other 364 days of the year everything else you do is going to feel sluggish and slow. High throughput alone is not enough for a good user experience. A very low round trip time when the network is idle is not enough for a good user experience, if the round trip time goes through the roof whenever the networking is being used. What we need is a good round trip time that remains good even when the network is being used. The good news is that we believe we know how to achieve this (e.g., L4S and similar), but unfortunately those solutions are not yet deployed.

Hence my email yesterday. I wanted to highlight Monday’s IPPM presentation by Christoph Paasch, Randall Meyer and William Hawkins, to highlight the need for development of more diagnostic tools, and to highlight the need for more awareness and routine usage of those tools.

For anyone interested to learn more, I also recommend this excellent report “Latency Explained” recently published by the Broadband Internet Technical Advisory Group. If you have people asking you what all this fuss about “latency” is about, and you don’t have the energy to explain it yourself every time, refer them to this report. In very clear terms it explains network latency (sometimes called “lag”), why it matters, what causes it, how to measure it, and what we can do about it.

<https://www.bitag.org/latency-explained.php>

Stuart Cheshire

P.S. When I took my measurements yesterday sitting in tcpm in Grand Klimt Hall 2 at IETF 113 in Vienna, I was surprised by the results, and hesitated about sending the email in case the results were bogus. But then I checked using the Bufferbloat Test provided by Waveform.com, and the data that showed confirnmed the Network Quality results.

<https://www.waveform.com/tools/bufferbloat>