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