Re: [Bloat] [e2e] [aqm] What is a good burst? -- AQM evaluation guidelines

[Jonathan Morton <chromatix99@gmail.com>]

On 16 Dec, 2013, at 3:47 pm, Naeem Khademi wrote:

> An example: when designing my AQM X should I care about 64K TSO-generated bursts to safely pass without dropping or not?

If there is at least 6Mbps bandwidth downstream of your queue, then codel at least will pass such a burst in isolation.

If you have ECN, then you should mark instead of dropping as long as you have queue space, and use FQ semantics to minimise latency impact on other flows.

> Does the answer (whatever it is) also apply to the burst sizes typical of multimedia traffic, etc.? if the answer is "yes", should an AQM design be actively aware of what application layer does in terms of sending bursty traffic or not? and to what extent if yes?    

That's a more interesting question.  IMHO the extremely bursty behaviour of certain popular video streaming systems is broken, and should not be worked around by the multitude of receivers - it should be corrected sender-side.  Relatively simple pacing algorithms which do this effectively are not difficult to design and, like much in the networking world, I am constantly surprised to find that they have not yet been deployed in earnest.

I am also reminded of the livestreamed demoscene event from a couple of years ago, which was producing enormous aggregate bursts every time a frame group completed encoding (multiple times a second).  This wasn't enough on a single flow to impact individual end-users much, but it overwhelmed the local and gateway buffers chronically, thereby crippling the entire livestreaming exercise until a workaround could be implemented.

So in short...  no.  Bursts of that magnitude need to be clipped, to signal to senders that they are problematic.

As an aside, networking infrastructure is unusual in that hardware innovation (bandwidth, buffer sizes) proceeds at a much faster pace than the associated software elements (which would normally develop in response to increased CPU power).  To some extent conservatism is explainable by a desire not to break things, but when things are already broken and need to be fixed...

 - Jonathan Morton