In this episode of PING, APNIC’s Chief Scientist Geoff Huston discusses the question of buffers, flow control and the ‘efficient’ use of a network link.
How do we maximize the use of a given network path, without knowing everything about its size along the way? It turns out, the story isn’t as simple as ‘more is better’ because sometimes, adding more memory to the system adds delay.
Modern TCP’s flow control algorithms are being modified to react to delay as well as loss and become more efficient at occupying the available space. At the same time, bit-marks inside the IP packet are modifying how end hosts can react to signals of congestion along the path. Are these two mechanisms in conflict? How do they stack up, and achieve critical mass in deployment?
Read more about TCP and flow control on the APNIC Blog. Here are some articles from the blog that discuss the issues:
- Comparing TCP and QUIC
- Does TCP keep pace with QUIC?
- TCP Congestion Signatures
- Striking a balance between bufferbloat and TCP queue oscillation
- TCP initial window configurations in the wild
- Underload: The future of congestion control
- Beyond bufferbloat: End-to-end congestion control cannot avoid latency spikes
- Congestion Control at IETF 110
Subscribe and share your story
You can stream and subscribe to PING via the following channels:
If you’re interested in sharing your insights or research, please get in touch — we’re always looking for great stories from the community. And please do let us know what you think of the podcast as well as the APNIC Blog so we can keep improving.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
One of these days, perhaps, multiplexing the needs of DNS, VOIP and videoconferencing traffic, and new techniques such as packet pacing, and fq_codel, will become more apparent.
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/
OK, I listened to the whole thing. A few comments:
A) Cubic, not reno, is probably the most common CC algorithm today, which does not decrease by half, but a 1/3rd, and has a cubic growth function to ease the cost of not dropping in half. I happen to think 1/2 is the more stable solution.
B) RFC3168 style ECN was defined in 2002, and available as a single sysctl option for TCP in all present operating systems. It is widely deployed in satcom systems, and defaults to on in fq_codel and fq_pie.
C) Ironically BBRv1 is the only one of our common CC algorithms that does not have any response to any form of ECN today. A switch or router that is using RFC3168 or L4S style ECN on a BBRv1 CC that negotiated it, will not drop packets, but send a clear delay signal to the BBR sender, which then finds a good rate, without packet loss, without even recognizing the ECN bits have been set! But it does tend to outcompete loss based CCs on a single queued link in that case. FQ solves this conflict on this mismatch of interpreting the bits.
It is kind of astonishing how much traffic is negotiating RFC3168 style ecn today. Whether anything is responding to it properly is up to measurements. I do not see it presented by DNS servers, for example, and mostly see it from apple products and at least one competing TV product.
BBRv1 also seems to have rate limits when wifi is involved because of the independence from the classic ack clock and the batchyness of acks on a half duplex wireless system.
D) BBRv2 on the other hand, does support (optionally) L4S style signaling at the switch or router, which is a multibit signal, with a brick wall setting the bits at a certain delay point, and reacts dynamically, but also according to it´s internal models, to such signalling.
TCP Prague and DCTCP also respond to L4S style signalling, but at a fixed rate reduction (IMHO) ill suited for jittery wireless links.
E) While I enjoyed your description of early ethernet I am still wishing you would talk about wifi a bit. I would come on your show to do that!
F) Lastly, the vast majority of flows never get out of slow start, and rarely hit additive increase, so they are typically doubling until they naturally end.