[Bloat] Buffer bloat at the sender [was: About Stochastic Fair Blue (SFB)]
Juliusz Chroboczek
jch at pps.jussieu.fr
Fri Feb 4 09:33:15 PST 2011
> Juliusz, have you thought about the host case at all?
> One of the places we're getting insane buffering is in the operating
> systems themselves (e.g. the experiment I did with a 100Mbps
> switch).
Yes. You have three to four layers of buffering:
(1) the device driver's buffer;
(2) the packet scheduler's buffer;
(3) TCP's buffer;
(4) the application's buffer.
It will come as no surprise to the readers of this list that (1) and (2)
are usually too large. For example, (1) the ath9k driver has a buffer
of 200 packets; and (2) the default scheduler queue is 1000 packets (!).
> My intuition is that we have to do AQM in hosts, not just routers.
Hmm... I would argue that the sending host is somewhat easier than the
intermediate router. In the sender, the driver/packet scheduler can
apply backpressure to the transport layer, to cause it to slow down
without the need for the lengthy feedback loop that dropping/delaying
a packet in an intermediate router has to rely on [1].
Unfortunately, at least under Linux, most drivers do not apply
backpressure correctly. Markus Kittenberger has recently determined [2]
that among b43-legacy, ath5k, ath9k and madwifi, only the former two do
the right thing.
--Juliusz
[1] Now why did we give up on source quench again?
[2] http://article.gmane.org/gmane.network.olsr.user/4264
More information about the Bloat
mailing list