Re: [Ecn-sane] [Bloat] The "Some Congestion Experienced" ECN codepoint - a new internet draft -

[Jonathan Morton <chromatix99@gmail.com>]

> On 11 Mar, 2019, at 5:29 pm, Holland, Jake <jholland@akamai.com> wrote:
> 
> The key difference to me is that L4S doesn't work without a dual queue.
> It embeds a major design decision ("how many queues should there be at
> a middle box?") into the codepoint, and comes with very narrow requirements
> on the sender's congestion control.

It's certainly unclear to me what happens when an L4S flow passes through a Classic ECN middlebox, especially one with only a single queue.  I get the impression that a DCTCP-like congestion response would tend to starve out conventional flows competing with it.  Unless you have data showing otherwise?

That has serious implications for incremental deployability, because you can't safely deploy L4S endpoints until single-queue Classic ECN middleboxes have all been replaced with L4S or flow-isolating types.  And without L4S endpoints in use, where's the impetus to do that?  Chicken and egg.

Conversely, an SCE-aware flow passing through a Classic ECN middlebox behaves just like a Classic ECN flow.  The only question arises when a single-queue AQM is made SCE-aware, and in that case the SCE-aware flows are the ones that might get outcompeted (ie. they are friendlier, not more aggressive).  If necessary, it would be easy to specify that single-queue AQMs "should not" produce SCE marks, only the flow-isolating types - which in any case are easier to deploy at edge devices where statistical multiplexing works less well.

Incremental deployability is very important when tackling a project as big as this.  SCE takes it as a central tenet. L4S appears, in practice, to have overlooked it.  That's my objection to L4S.

 - Jonathan Morton