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

[Bob Briscoe <[e-mail]>]

Richard,

I've replied separately to Greg - apologies for splitting the thread. Inline...

At 13:18 12/11/2013, Scheffenegger, Richard wrote:
>Hi Greg et.al.,
>
>(chair hat off)
>
> > I don't have a lot of confidence that I can recommend something to be
> > burned into silicon at this point (and doing it in software is a non-
> > starter).  The "turned on or off by operators later" would be a given, but
> > if implemented based on what we know now, I don't have a lot of confidence
> > that the switch would be ever set to the "turned on" state.  I can't
> > recommend that vendors add gates for a feature that my intuition tells me
> > would never be used.  If separately configurable means something that
> > would increase the probability of the feature being used, then that's
> > great, but what specifically are we talking about?  It could be a lot of
> > gates.
>
>So, as I am not a HW guy, how many gates does one need for (W)RED, PIE, CoDel?
>
>Apparently, as state needs to be kept separately 
>for ECN and non-ECN flows, additional memory 
>plus some way of switching between which memory 
>is used for what packet is necessary; however, 
>the hardcoded algos should be the same (as far 
>as some tuneables are stored in memory instead of hardwired gates).

I'll let the hw people answer that, but it seems a reasonable point.


> > Also, you've suggested *not* differentiating between "classic ECN" and
> > "immediate ECN" in the ECT flags, but this is just a suggestion at this
> > point.  Again, not something I feel confident about taking for granted.
> > We'll continue to track this discussion though.
>
>As Bob pointed out in another email, classic ECN 
>will react to any number of marks within one RTT 
>(of that particular flow) with only a single 
>halving of the congestion window. Most other 
>transports that have been modeled after TCP/ECN 
>will behave similarly. Immediate ECN will react 
>to each mark to a smaller extent, and only a 
>full window (RTT) of marks will reduce the 
>window by half. Thus immediate ECN would be much 
>more aggressive when used with traditional RED, 
>ie. push the AQM to higher marking probabilities.

The paper (available on request, because still 
under submission) records experiments that show 
we can get equal rates between otherwise 
equivalent ECN and drop flows as long as the 
parameters of the two ramps are connected by a 
formula. This formula was found by fitting to the 
very clear curve visible along the ridge of the 
3-D plot on our slide 11 
<http://www.ietf.org/proceedings/88/slides/slides-88-tsvwg-20.pdf>.

I'm sure this will not be the whole story, but 
it's a good start. I believe that such parameter 
settings only lead to equal rates between an ECN 
and a drop flow for one of each type of flow. I 
won't be particularly worried if the relative 
rates stray from precise equality under different 
conditions, as long as there is no starvation, 
and they remain in the same ball-park.


>One venue that presents itself here, of course, 
>is to use 2nd order effect - i.e. the exact 
>marking pattern - to achive reasonable fairness 
>between transports making use of immediate and 
>classic reactions. However, I can not say 
>offhand, if this would be a practical method 
>(may require too much state in the 
>scheduling/aqm, including fine grained flow separation).

Hopefully we won't need to go there.


> > However, it seemed to me that what you were proposing was to move the
> > intelligence to the transport, and keep the queue simple. In that regard,
> > would a very simple threshold:  always mark when instantaneous queue
> > exceeds the threshold, never mark when it doesn¹t, be an acceptable way to
> > do things?
> >
> > This would be easily implementable, and could be straightforwardly
> > combined (I think) with any AQM that is controlling drops (including
> > CoDel).
>
>That is what DCTCP currently does.

I wasn't aware that DCTCP was already being used 
alongside non-ECN traffic. Is this what you meant?

>However, a simple step function is incompatible with classic ECN.

I think you mean classic ECN TCP flows. If so, I 
wouldn't state this quite so strongly (yet). I 
suspect there will be conditions where a classic 
ECN TCP will be somewhat disadvantaged. However, we need experiments to see:
* whether the disadvantage is slight,
* how many classic ECN hosts might be affected,
* and the likelihood that their owners would 
rapidly upgrade them (AFAIK, their owners must 
have already intervened manually for ECN hosts to 
already be in the wild, given I believe ECN is 
turned off by default in TCP clients under the major operating systems).


>While reading Bob's earlier comment on classic 
>vs immediate ECN, I thought that probably an 
>exponential increase in marking probability, 
>above a specific threshold (lower than drop) 
>could "autotune" to a reasonable marking rate, 
>without necessarily locking classic out when 
>immediate is used. If the linear/step function 
>employed with RED (and shown on Bobs slides) is 
>a good enough approximation needs to be 
>verified. However, the details will probably 
>also depend on the mixure of number of classic 
>vs. immediate ECN flows at the bottleneck, and their respective RTTs...

Agreed.


>Finally, as the gateways (switches) cannot rely 
>on ECN to work (either on the required 
>timescales, as the RTT is too large for small 
>buffers, or the transport/sender is not 
>reacting), even ECN traffic has to be exposed to drops

Agreed

>  - and ideally here not to the tail-drop variant.

It may not be necessary to switch an ECN flow to 
AQM-generated drops - it may be sufficient to 
switch both ECN and drop traffic to tail drop at 
the same time - when load exceeds the operating 
region of the AQM as a whole. But, you may be right - needs more experiments.


Bob



>Richard Scheffenegger
>
>
>_______________________________________________
>aqm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/aqm

________________________________________________________________
Bob Briscoe,                                                  BT