Re: [aqm] [tsvwg] Immediate ECN: Autotuning AQM for RTT

[" Ilpo Järvinen " <[e-mail]>]

On Tue, 12 Nov 2013, Bob Briscoe wrote:

> Greg, inline...
> 
> At 18:57 11/11/2013, Greg White wrote:
> 
> 
> > On 11/11/13, 9:02 AM, "Bob Briscoe" <[e-mail]> wrote:
> > 
> > >Greg,
> > >
> > >At 06:54 09/11/2013, Greg White wrote:
> > >
> > >>Bob, CoDel uses "interval" both as a hold-off for the first packet drop
> > >>and as the numerator in the invsqrt drop scheduling.  Setting interval =
> > >>0
> > >>would result in ECN being signaled on *every* ECN capable packet when the
> > >>sojourn time is above threshold.    This jibes with some of your charts
> > >>for RED, but others show a ramp up in mark probability rather than a step
> > >>function. Could you clarify?
> > >
> > >We've only looked at WRED in detail, because it was much more
> > >interesting (to us) to reconfigure existing implementations than have
> > >to wait for new code to be implemented and tested.
> > >
> > >The suggestions for PIE and CoDel are just conceptual at this stage -
> > >we've done no implementation of this idea with either. (I said this
> > >verbally when presenting the slides, but I should have put it in
> > >writing too). Please read my suggestions for PIE and CoDel in this light.
> > >
> > >I'm not surprised that CoDel derives other parameters from 'interval'
> > >that should have been declared and set separately. Andrew McGregor
> > >also pointed out to me that CoDel sets threshold = 0.2*interval, so
> > >threshold would have to be declared separately as well. This starts
> > >to reveal just how many magic numbers there really are in the CoDel
> > >algorithm.

Btw, Van & Kathleen say about this in ID:

"A CoDel control law more independent of interval is future work."

I suppose it still is...

> > To be more clear about my earlier statement, CoDel actually uses
> > "interval" to control a single aspect of the drop policy, however, the
> > code (and descriptions of it) imply that there are two different
> > functions, and my comments above were written in that vein. However,
> > here's how I would describe it more succinctly:  the "next drop time" is
> > always set according to interval/sqrt(count).  In the specific case of
> > sojourn time crossing above threshold from below, count happens to equal
> > 1, so the first drop is set at one interval in the future.  This is what
> > is sometimes described as the "hold off" period.
> 
> OK. From an admittedly hasty scan through Andrew McGregor's port of CoDel to
> ns3 (not the Linux code), it seems to introduce this hold-off time in the
> ControlLaw() function, but it only calls ControlLaw() from the ShouldDrop()
> function if the queue has remained above threshold for duration interval.
> 
> That implies that CoDel holds off signalling anything for 2 * interval, ie
> 200ms for the default setting of interval = 100ms.

There are two calls to it at least in the ID. CoDel is also implemented 
like that in ns2, Linux, and (based on very brief check) also in ns3. The 
first call happens exactly at interval, not two away from crossing the 
target (/threshold) delay. Both calls are preceded by a "drop" (/signal).


-- 
 i.