> On 11 Mar, 2019, at 5:29 pm, Holland, Jake <jholl...@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
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
