Re: [aqm] ECT(1)

[John Leslie <[e-mail]>]

Jonathan Morton <[e-mail]> wrote:
> 
> A flow-isolating AQM such as fq_codel would be able to deal with different
> flows responding differently to CE.

   Flow-isolating AQMs, however, don't have a sufficient way to tell
whether a flow wants DCTCP-like signals.

   The fundamental question Bob Briscoe raises is how to make better
use of ECN-marking. He argues that DCTCP's "1/p" marking gives much
better information.

> The problem is that core and semi-core network nodes don't have the
> resources to do flow isolation at line rate, or (equivalently) they
> deal with too many simultaneous flows to make a meaningful flow
> isolation scheme practically implementable.  This, I assume, is
> where the dual queue proposal comes in.

   I wouldn't assume that.

   I know that Bob is thinking about dualq for the first hop (and that
IMHO is why he likes DSCP as a distinguishing mark which will survive
the first few hops).

> Fundamentally, dual queue needs to be able to identify the packets
> belonging to each queue.

   Yes.

> DSCP is a non-starter because it doesn't, in practice, survive end
> to end.

   That worries me, too.

> I'm wary of using the ECN field for the same purpose - it could work,
> but promotimg CE packets from classic ECN flows could result in
> spurious retransmissions due to reordering.

   That is a serious issue, though hard to see for the casual reader.
Bob proposes that ECT(1) mark the choice to use "1/p" marking; but he
also proposes that any packet already marked CE go through the same
"1/p" queue. I don't agree that's good.

> Simply using the presence of ECN capability is also a bad idea,
> because Apple's imminent deployment of classic ECN to millions of
> end hosts will break that assumption.

   Yes. (Not that the issue doesn't _already_ exist...)

> A more robust deployment option would be to use a new transport protocol
> ID.  Then it wouldn't be TCP any more, and you can throw away some cruft
> while you're at it.  I'll leave the problems with that idea to your fertile
> imaginations.

   ;^)

> As a gentle reminder, ELR is designed to solve the same problem while
> avoiding these deployment problems.  It does "burn" ECT(1), but for a
> good cause and - crucially - doesn't require the network to be aware
> of it before endpoints can safely turn it on.

   Neither scheme, IMHO, can work unless we deprecate ECN Nonce. That
should be a no-brainer (IMHO) since ECN Nonce was experimental, with
a very clear statement of intent to submit as Proposed Standard after
experience showed it to be useful; and that hasn't happened in twelve
years.

   Once we deprecate ECN Nonce, we can address the question of what use
of ECT(1) is best. My current belief is that the "1/p" marking would be
the best use; but there are many issues to consider.

--
John Leslie <[e-mail]>