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

[Bob Briscoe <[e-mail]>]

Dave & Fred, (two birds in one posting)

At 02:06 12/07/2013, Fred Baker (fred) wrote:

>On Jul 11, 2013, at 5:15 PM, Bob Briscoe <[e-mail]>
>  wrote:
>
> > 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.
>
>I'm all for that. Maybe we can get the WG, if there is one, to add a 
>document describing that, or add text to the AQM recommendation. 
>Suggest text/approach?
>
>I'd suggest perhaps discussing this in Berlin.

Fred, Altho I said it originally, I'm not sure how much we can or 
should write down about the basic art of controlling stuff. A 
standards body is good for people who want to check that product X 
has features a,b,&c. It's not necessarily the right place to write 
documents for Mr Brown in procurement to check that the subtleties of 
algorithm Y comply with articles d,e&f of control theory.

>At 02:49 12/07/2013, Dave Taht wrote
>[Bob Brisoe has copied this response across from another thread, 
>'cos it was written in response to this point about auto-tuning]:
>
>The sqrt->linear drop approach is tcp friendly and currently works
>well on a wide range of RTTs. It certainly seems like a worthwhile
>research effort to measure and act on the slope of the curve, both up
>and down, in a codel variant, in order to get better results faster.

Dave, Setting aside TCP-friendly for a minute, depending on the slope 
would be research yes. But let's get the basics first. The only thing 
that depends on queue delay (in the CoDel drop code I looked at) was 
when drop started and when it stopped. In between, the pattern of 
gaps between the drops was pre-ordained and hard coded. If the queue 
was growing ridiculously long (e.g. due to a flash crowd), CoDel 
still laboriously decreased the gap between each drop in its 
preordained pattern.

I hope that's been improved in more recent CoDel code. This is the 
basic structure of an algo - I'd hardly even call it auto-tuning, 
it's about ensuring the intensity of the dropping within the 
algorithm depends on the effect it is trying to control.

Similarly, the delay before dropping starts is completely independent 
of whether the queue  has been slightly above 'target' for 'interval' 
or queue delay has headed off into the stratosphere during 
'interval'. IOW, I would challenge that the very use of the min() 
function in CoDel is counter to auto-tuning (auto-controlling) principles.

________
Finally, I can't resist having a snipe at that TCP-friendly sentence. 
If you can justify it I would be most impressed. It looked like BS 
when I saw it in VJ/Nichols paper, and it still looks like BS. That 
sqrt is relative to the count of drops, which is nothing to do with 
the sqrt in the TCP formula. It's as likely to be related to 
mass-energy equivalence, because that's got a square term in it too.

[Anyway, only Reno congestion window is proportional to 1/p^0.5. The 
cwnd of Cubic & Compound are proportional to 1/p^0.75 and 1/p^0.8 
respectively.]



Bob


________________________________________________________________
Bob Briscoe,                                                  BT