Subject: [aqm] Questioning the goal of a hard delay target

From: Bob Briscoe <[email-masked]>
Date: Fri, 03 Jul 2015 13:20:24 +0100

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/

---

From: Simon Barber <[email-masked]>
Date: Fri, 03 Jul 2015 10:34:26 -0700

Hi Bob,

Very interesting to see this. I had just recently privately proposed an 
extension to Codel - to auto tune the target parameter. The proposal is 
to observe the characteristics that are exhibited when target is too 
large or too small, and make adjustments appropriately. i.e. if you make 
a single drop during an interval, and the response of the flow is to go 
idle (even momentarily) then perhaps it was because target is too small. 
Using some rule you could increase target. Conversely you can 
heuristically identify when target is likely too large, and reduce it.

Simon

On 7/3/2015 5:20 AM, Bob Briscoe wrote:
> 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:
> 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.
>
> 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.
>
> with different parameters for higher link capacity, and when you 
> don't. It gives the formula for how to set the config too.
>
> _______________________________________________
> aqm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/aqm

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 03 Jul 2015 18:42:41 +0100

Simon,

Y, if you're going to start autoadjusting a hard-coded parameter, you 
have to first question whether it was right to choose that parameter to 
hard-code in the first place.

Bob

On 03/07/15 18:34, Simon Barber wrote:
> Hi Bob,
>
> Very interesting to see this. I had just recently privately proposed 
> an extension to Codel - to auto tune the target parameter. The 
> proposal is to observe the characteristics that are exhibited when 
> target is too large or too small, and make adjustments appropriately. 
> i.e. if you make a single drop during an interval, and the response of 
> the flow is to go idle (even momentarily) then perhaps it was because 
> target is too small. Using some rule you could increase target. 
> Conversely you can heuristically identify when target is likely too 
> large, and reduce it.
>
> Simon
>
>> 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:

---

From: Dave Taht <[email-masked]>
Date: Fri, 3 Jul 2015 12:12:44 -0700

On Fri, Jul 3, 2015 at 10:42 AM, Bob Briscoe <[email-masked]> wrote:
> Simon,
>
> Y, if you're going to start autoadjusting a hard-coded parameter, you have
> to first question whether it was right to choose that parameter to hard-code
> in the first place.

In codel, target was never a hardcoded parameter. It has always been
specified as "5-10% of the interval", with a default of 5% (which
equals 5ms on an interval of 100ms. In retrospect I really wish we had
made it be an actual percentage in the code and configuration, and on
other days wish we had only exposed interval as a parameter).

We have always thought target in the case of wifi especially needed to
be a function of "active stations". This is sort of where cake is
going.

Target is merely a delay that codel *aims for*. When it hits a drop
rate (or the flow slows down) enough - it turns off, and the algorithm
goes into behavior that only goes on again after the delay exceeds
target for the current computed interval.

It is good to have some new thinking on this, of course, and codifying
how to modify the target - or work on different curves on various
other algorithms, is wonderful. I like bob's other piece on smaller
cwnds to keep "the tcp signal strength up", but am not as allergic as
he to reducing mss in such cases.

One of these days, perhaps, someone will successfully write up and
explain the 3 modes of codel. People look too hard at the ramp up
portion of the algo and not at what happens when you are at or near
steady state. I would like to develop a model that shows what is going
on in all the queues, all the time, and presents it graphically,
somehow.

>> extension to Codel - to auto tune the target parameter. The proposal is to
>> observe the characteristics that are exhibited when target is too large or
>> too small, and make adjustments appropriately. i.e. if you make a single
>> drop during an interval, and the response of the flow is to go idle (even
>> momentarily) then perhaps it was because target is too small. Using some
>> rule you could increase target. Conversely you can heuristically identify
>> when target is likely too large, and reduce it.
>>
>> Simon
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>> 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.
>>>

-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast