[aqm] ECT(1)

[John Leslie <[e-mail]>]

Scheffenegger, Richard <[e-mail]> wrote:
> 
> Regarding the identifier to differentiate legacy ECN (cc reaction on
> ECN per RTT = cc reaction to loss in RTT) and the differentiated
> response (proportional to the # of CEs per RTT) is an open question.

   Wide open!

> Perhaps we can start to gather the views of the group on this list
> already; There have been other uses for ECT(1) been proposed over
> time, and it has also been pointed out that repurposing a DiffServ
> Codepoint may not be the easierst to do from a procedural view.

   Nor (IMHO) is a repurposed DiffServ Codepoint likely to work well.

   OTOH, I think the time is ripe to deprecate ECN Nonce; and reserve
ECT(1) for (currently) Experimental uses.

   We could pretty easily combine that with an IP Option to define the
particular experiment, and even record data about forwarding node action.
(Admittedly, this is more difficult in IPv6, so I suggest initially
considering IPv4; and then adding an IPv6 kludge, probably hop-by-hop.)

   IMHO, the only other uses for ECT(1) that have approached "traction"
relate to differentiation of forwarder action for ECN marking.

> Also, I would like to encourage members of the aqm wg to review the various
> versions of http://tools.ietf.org/html/draft-kuehlewind-tcpm-accurate-ecn
> (the technical content did change in each version substantially).
> Disclaimer, I'm one of the authors of that draft.

   I believe I've reviewed them all; but is it truly reasonable to expect
all WG members to review more than the latest one?

   Fundamentally, the latest version calls for three counters, to be
masked to low-order bits reporting changes in the counters. There are
three possibilities on _where_ these bits will be reported. (I'd rather
not bike-shed the virtues of each yet...)

   draft-briscoe-aqm-dualq-coupled does not appear to have been posted
yet: I'll be only too happy to discuss it once it is...

   Fundamentally, it proposes to identify a separate low-latency queue
which will report via ECN a near-zero-latency condition (vs. a zero
congestion in this second queue), while the default queue operates by
a legacy AQM mecanism, probably signaled by packet drop.

   This strikes me as Experimental: there are a number of issues, such
as how this low-latency queue overflows and what happens when it does,
which need to be resolved before we could even consider Standards Track.
At first blush, this looks like a good match for Experimental use of
ECT(1).

--
John Leslie <[e-mail]>