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/
_______________________________________________
aqm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/aqm
