[e2e] Deflating excessive buffers
Martin.Heusse at imag.fr
Mon Sep 22 12:17:44 PDT 2014
Dear E2E list,
in case it matches your curiosity, I wanted to point to the work we just presented at ITC'26 and maybe gather your comments (T. Braud, M. Heusse, A. Duda: "TCP over Large Buffers: When Adding Traffic Improves Latency"). (BTW, I don't see too many people talking about their work, so I'm not sure it's the usage to do this... But since my posts to this list were sometimes sarcastic I also thought it would be an opportunity to contribute in a different way!)
The has been many exchanges on this list about the impact of having excessively large buffers at the head of the bottleneck link, which increases queueing delay and hurts link utilization --often in the downlink direction, whereas the congestion is more often in the uplink direction (bufferbloat, combined with upload/download interference).
We showed that (assuming the uplink is congested):
1- sending a small amount of tiny packets (small bitrate, significant packet rate) into the uplink buffer, they occupy the unnecessary (so to speak) buffer slots and reduce the apparent buffer size, which in turn reduces queueing delay. The gain may be quite significant (halve the response time for instance). Do you know many examples where sending more packets speeds things up?
2- Actually, an intense load in the downlink direction has a similar effect: many ACKs enter the uplink buffer at times, which is enough to make it overflow and calm down uploads. This effect may explain why a case of "bufferbloat" may not always be as bad as it could be.
Incidentally, the paper pits popular variants of TCP against each other in various setups.
More information about the end2end-interest