Re: [aqm] Question re draft-baker-aqm-recommendations recomendation #2

[Bob Briscoe <[e-mail]>]

Dave,

At 17:40 30/04/2013, Dave Taht wrote:
>On Tue, Apr 30, 2013 at 9:29 AM, Wesley Eddy <[e-mail]> wrote:
> > On 4/29/2013 10:00 AM, Fred Baker (fred) wrote:
> >> Do we generally agree with the recommendation of 
> http://tools.ietf.org/html/draft-baker-aqm-recommendation-01#section-4.2? 
> This is the question of signaling to an endpoint using both dropping and ECN.
> > The second part (imposing an upper bound) might be worth expanding a
> > bit.  I don't know what a reasonable upper bound is, for failing into
> > a tail-drop mode,
>
>No reason to specify "tail" drop here.

I agree with you here that it doesn't have to be tail-drop. But I 
would add that we need to record the lessons learned in the past, not 
just say "drop" and hope people understand.


1/ The RED algo was defined such that at a configured length of the 
smoothed queue it rose to 100% drop probability. When that was 
initially implemented in alt_q, it allowed an unresponsive flow to 
turn RED into a DOS amplifier, because 100% drop = 0% throughput. Of 
course, once the algo drops 100% of incoming traffic, the smoothed 
queue will reduce and the drop prob will reduce, but this led to 
unstable behaviour.

In the alt_q RED code you can still see this 100% drop stuff that 
Kenjiro Cho commented out, and replaced with fall-back to tail drop.

When I last looked at the CoDel code (which wasn't recently), if 
unresponsive traffic was keeping the queue above threshold, it used 
the drop_next_ variable to continually decrease the time between 
drops until it would eventually drop 100%. I figured it was likely 
the same instability would ensue. You may have fixed this since, 
given CoDel performed badly with unresponsive traffic in the early tests.

My point is that we need to record this advice, because everyone 
seems to start out making the same mistake - the boundary conditions 
of the algos get overlooked, and they are important for Internet stability.

So we should give examples of good and bad approaches for the 
boundary conditions. An example of a good simple strategy would be 
something very much like tail drop, but where the 'tail' is a fixed 
tight delay cap, not the tail of the buffer.



BTW #1, once in dropping mode, the CoDel code that I looked at 
initially took the square-root of the count of drops to decrease the 
time between drops. Ironically this leads to a /linear/ increase in 
drop frequency over /time/. So I'm sure there should be a much 
simpler way to code it without the square root, by driving drops from 
elapsed time not drop count.

BTW #2, in that same CoDel code, the dropping pattern once in the 
dropping mode did not depend on how large the queuing delay was 
getting - it was all pre-ordained how it would behave. Again, this 
may have since been fixed, but to me it seemed very wrong not to drop 
more frequently if the queuing delay was getting longer and longer.

When I looked at the original CoDel code, I just thought the word 
auto-tuning was being used as empty marketing BS. It's use of service 
time certainly auto-tuned the queue threshold to the link rate. 
However, in both its modes it didn't change how quickly it responded 
dependent on how bad the problem had become.

As an output of this proposed AQM WG, I would like to see advice that 
says what auto-tuning means, not just the empty word "auto-tuning", 
ie. not just using time as the unit of queuing, but also an AQM 
should not take a hard-coded time to respond irrespective of how much 
the queuing delay has grown.


[Sorry for responding nearly 2 months late (I'm just catching up on 
stuff that arrived while I was tuned out from the AQM list, due to other work)]


Bob



________________________________________________________________
Bob Briscoe,                                                  BT