Improving the Internet's Responsiveness
How well does the internet work for us?
A Quick Plug
Episode 85: Bufferbloat
Katherine Druckman and Doc Searls talk to Dave Taht about bufferbloat, latency, and the issues plaguing our networks.
Please remember to subscribe via the podcast player of your choice.
Last week’s show, Episode 85, is one of our most technical ones; but also one of the most important, because it involves how well the Internet actually works for each and all of us.
Take the matter of AQM: Active Queue Management. AQM keeps latencies (lag times) low. Poor or nonexistent AQM, rather than low bandwidth, is one of the main reasons that images and sound uploads can break up Zoom, FaceTime and other common calls over the Net. Given how much that kind of activity is becoming a primary way to use the Internet, it is hugely important for AQM to be deployed and work well.
One approach to that is DOCSIS-PIE, or PIE for short. (It stands for "Proportional Integral Controller Enhanced.") According to this paper, "For the device with AQM, the large majority of the latency under load tests resulted in 15-30 milliseconds of latency. In comparison, the device without AQM averaged roughly 250 milliseconds of latency – between 8-16 times higher – a highly significant difference to the end user quality of experience (QoE)."
PIE is the kind of civil engineering work on the Internet that happens all the time out of the public eye. This work often involves productive cooperation between the big entities putting the Internet's base protocols to work (for example, cable and phone companies), and independent queue theorists such as Dave, in an organization called the IETF. In fact, Dave singles out Comcast, which provides many of us Internet service through its Xfinity brand, as one of the good guys, in fact being one of the few ISPs actively investing in Open Source, and especially WiFi, via the Comcast
As a separate matter, there is a new non-improvement to the Internet, led by some of the same big companies, called "Low-latency, low-loss, scalable throughput," or L4S for short. Here's a paper explaining it: Operational Guidance for Deployment of L4S in the Internet. Dave says L4S is meant to privilege some data flows, giving them a "fast lane" on the Internet while initially leveraging docsis pie to provide that initial, well agreed upon, truly fair, performance enhancement to the internet.
Dave calls this “the battle over the last bit in the IP header”. Should that bit be used to divide the internet in two, giving a performance advantage to ISP servers and specialized applications kept close to the ISP's network? Or used to provide better congestion signaling end to end, in a backwards compatible way for all applications? Or not used up at all, as Dave thinks neither approach can work. This battle is holding up deployments of docsis-pie, sch_cake, and fq_ codel when deployment of the proven AQM algorithms is direly needed to improve internet access for all stuck, working from home, suffering from latency stress and network glitches.
Still, it's interesting to witness the debate, for example reading that the BigCos are busy caring about "fairness" toward uses they favor.
Among other interesting and hyper-relevant things, Dave describes a simple hack that SpaceX's Starlink can use to make good on its promise of low-latency Internet service from space.
Dave also pointed us at the (now concluded) Internet Architecture Board workshop, keynoted by Vint Cerf, where among many other things, Matt Mathis of
Google Measurement Labs described a marked (3-fold!) improvement in
Internet responsiveness over the last 5 years for some ISPs, and Apple explained their new Network Responsiveness tool and metric, which is in beta now, and will be released in the next iOS and OSX versions.
Back on the ground, you should check out what you can do to maximize the quality of your own connection using SQM (Smart Queue Management), developed by Dave and his colleagues in the OpenWrt project.
If you care about the way the Internet actually works, and what great hackers are doing to make sure it works well, this is a show not to miss.
* It’s worth noting that Dave Taht's work has been funded by NLNET, Google fiber and the Comcast Innovation Fund.
This Week’s Reading List
Postcards from the Bleeding Edge — David Täht writes about politics, space, copyright, the internet, audio software, operating systems and surfing.
Does my modem have Active Queue Management (AQM) for low latency? | Xfinity Community Forum — Does my modem have Active Queue Management (AQM) for low latency?
RFC 8290 - The Flow Queue CoDel Packet Scheduler and Active Queue Management Algorithm
Bufferbloat.net - Bufferbloat.net — Bufferbloat is the undesirable latency that comes from a router or other network equipment buffering too much data.
Cerowrt Wiki - Bufferbloat.net — The CeroWrt Project is complete. The last build (3.10.50-1) was released in July 2014. The principles learned from that research project have been transferred to the Linux kernel and OpenWrt.
The congestion-notification conflict [LWN.net] — Most of the time, the dreary work of writing protocol standards at organizations like the IETF and beyond happens in the background, with most of us being blissfully unaware of what is happening. Recently, though, a disagreement over protocols for congestion notification and latency reduction has come to a head in a somewhat messy conflict. The outcome of this discussion may well affect how well the Internet of the future works — and whether Linux systems can remain first-class citizens of that net.
Objections to L4S WGLC — This document is a companion to a pair of slides presented at the IETF-111 TSVWG session. Due to time and space constraints, the slides could only contain a bare listing of the most pertinent, purely technical issues. This document illustrates and links to concrete data supporting the relevance of those issues, and amplifies them with further relevant issues. The bullet points from the slides are quoted, followed by supporting material.
Operational Guidance for Deployment of L4S in the Internet — This document is intended to provide guidance in order to ensure successful deployment of Low Latency Low Loss Scalable throughput (L4S) in the Internet. Other L4S documents provide guidance for running an L4S experiment, but this document is focused solely on potential interactions between L4S flows and flows using the original ('Classic') ECN over a Classic ECN bottleneck link. The document discusses the potential outcomes of these interactions, describes mechanisms to detect the presence of Classic ECN bottlenecks, and identifies opportunities to prevent and/or detect and resolve fairness problems in such networks. This guidance is aimed at operators of end-systems, operators of networks, and researchers.
draft-ietf-tsvwg-aqm-dualq-coupled-16 - DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
[OpenWrt Wiki] SQM Details — If you want to set up SQM to minimize bufferbloat, you should start at the SQM Howto page.
SpaceX nicknames Starlink Internet user terminal 'Dishy McFlatface' — SpaceX started to offer Starlink satellite broadband internet this week. The company sent out e-mails to potential customers who would want to beta test the Starlink network in its early phase. SpaceX currently operates approximately 888 Starlink satellites in low Earth orbit out of thousands it plans to deploy to provide broadband coverage globally. Starlink is initially providing service to the northern United States and southern Canada. SpaceX states that by 2021 the company will provide service to 'the populated world'.
Stay safe out there! Until next time!
Thank you especially to our Patreon and Ko-fi supporters who help us keep the podcast and newsletter going!
Note: Please add us to your address book so we don’t end up in your spam folder.
If you enjoyed this edition, please click the heart below to let us know!