[Bloat] Detecting bufferbloat from outside a node

[Neil Davies]

On 4 May 2015, at 12:33, Jonathan Morton <chromatix99 at gmail.com> wrote:

> 
>> On 4 May, 2015, at 13:42, Neil Davies <neil.davies at pnsol.com> wrote:
>> 
>> Noting that, delay and loss is, of course, a natural consequence of having a shared medium
> 
> Not so.  Delay and loss are inherent to link oversubscription, not to contention.  Without ECN, delay is traded off against loss by the size of the buffer; a higher loss rate keeps the queue shorter and thus the induced delay lower.

Sorry Jonathan - that’s not what we’ve observed. We’ve measured “excessive” delay on links that are averagely loaded << 0.1% (as measured over a 15 min period) - I can supply pointers to the graphs for that. 

> 
> You can have just as much delay and loss in a single flow on a dedicated, point-to-point, full-duplex link (in other words, one that is *not* a shared medium) as on the same link with multiple flows contending for it.

A single flow can contend the medium just as much as a multiple ones - it is the total arrival pattern that is important, which may be related to the number of flows (in that there is more freedom in the system).

> 
> Conversely, we can demonstrate almost zero flow-to-flow induced delay and zero loss by adding AQM, FQ and ECN, even in a fairly heavy multi-flow, multi-host scenario.
> 
> AQM with ECN solves the oversubscription problem (send rates will oscillate around the true link rate instead of exceeding it), without causing packet loss (because ECN can signal congestion instead), and FQ further reduces the most easily perceived delay (ie. flow-to-flow induced) as well as improving fairness.
> 
> Of course, loss can also be caused by poor link quality, but that’s an entirely separate problem.

It is a separate cause, agreed, but it has a similar effect...

> 
> - Jonathan Morton
>