[Bloat] Buffer bloat at the sender [was: About Stochastic Fair Blue (SFB)]

[Juliusz Chroboczek <jch@pps.jussieu.fr>]

> 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