Deflating excessive buffers
Martin Heusse <Martin.Heusse <at> imag.fr>
2014-09-22 19:17:44 GMT
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
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.