[aqm] Questioning the goal of a hard delay target

[Bob Briscoe <[e-mail]>]

AQM chairs and list,

1) Delay-loss tradeoff

We (Koen de Schepper and I) have designed an AQM aimed at removing the 
need for low delay QoS classes, initially as a cost/complexity reduction 
exercise for broadband remote access servers (BRASs). One of the 
requirements given to us was:
* As background load increases, delay-sensitive apps previously given 
priority QoS treatment (e.g. voice, conversational video) should 
continue to get the same QoS as they got with Diffserv.

We found that AQMs with a hard delay threshold (PIE, CoDel) have to 
drive up loss really high in order to maintain the hard cap on delay. 
The levels of loss start to cause QoS problems for voice, even tho delay 
is fine. Indeed, we found that the high levels of loss become the 
dominant cause of delay for Web traffic, due to tail losses and timeouts.

Everyone has been focusing on delay, but we've not been noticing 
consequent really bad loss levels at high load.

Once you know where to look, the problem is easy to grasp: As load 
increases, the bottleneck link has to get each TCP flow to go slower to 
use a smaller share of the link. The network can increase either drop or 
RTT. If it holds queuing delay (and therefore RTT) constant (as PIE and 
CoDel do), it has to increase drop more.

We found that by softening the delay threshold a little, at high load we 
don't need crazy loss levels to keep delay within bounds.
BTW, the implementation needs fewer operations per packet than RED, PIE 
or CoDel.

Conversely, at low load, a hard queuing delay threshold also means that 
delay will be /higher/ than it needs to be.

I've written up a brief (4pp) tech report quantifying the problem 
analytically.
<http://www.bobbriscoe.net/projects/latency/credi_tr.pdf>

Koen and colleagues have since done thousands of experiments on their 
broadband testbed with real equipment. It's looking good, even before 
we've explored varying what we call the 'curviness' parameter (which 
varies how hard the target it). We have a paper under submission with 
all the results, which we'll post as soon as it's not sub judice.


2) Does Flow Aggregation Increase or Decrease the Queue?

Something else had been bugging me about how queue lengths vary with 
load: The above argument explains how more TCP flows /increase/ the 
queue. But queues are meant to get /smaller/ at higher levels of 
aggregation.

The second half of the above tech report explains why there's no 
paradox. And it goes on to explain when you have to configure an AQM 
with different parameters for higher link capacity, and when you don't. 
It gives the formula for how to set the config too.

Writing this all down cleared up a lot of nagging doubts I had in my 
mind. I hope it helps others too.



Bob

PS. Note my new interim email @.



>
>
> -- 
> ________________________________________________________________
> Bob Briscoe                               http://bobbriscoe.net/