Re: [tsvwg] [Bloat] [Ecn-sane] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Jonathan Morton <[e-mail]>]

> On 20 Mar, 2019, at 10:12 am, Ingemar Johansson S <[e-mail]> wrote:
> 
> The L4S work has been very open and people
> like Bob Briscoe have always been ready to answer questions (except for
> cases when his email-queue has been bloated). Therefore I wonder why
> proponents of the SCE work have been so silent up until now ?. Being this
> silent for several years, just to step forward now to say "hey!, all this is
> crap, we have something much better" doesn't cut it.

One reason we've been quiet about L4S is because we've been busy with other stuff (such as Cake), and searching for funding to continue work in this area.  Unlike L4S, we do not enjoy the enthusiastic support of a very wealthy cable industry.

When L4S was initially proposed and described, we did speak up about our concerns with its design.  L4S then essentially "submarined" with little public activity for a long time, so we assumed it had stagnated and thus paid little attention to it.  Those concerns have not been satisfactorily addressed as far as we have seen, which is why we're now asking for pointers to more detailed information.  We also now discover that one explanation for L4S' lack of *public* activity is so as not to preclude patenting of key algorithms in its design.

For my part, I'm asking about TCP Prague's protection against running through a single-queue, Classic ECN bottleneck in competition with conventional flows, as that is the most obvious barrier to L4S being incrementally deployable.

So far I'm only being told that such protection exists, but given nothing that reassures me that such protection will be effective in practice, whilst not triggering false positives from every home wifi setup currently deployed.  That includes running a Google search for "TCP Prague", which I would normally expect to turn up a detailed spec under these circumstances, rather than some slide decks and what amounts to a wishlist.

And, rather than simply say "this is crap", we are trying to offer a viable alternative in SCE.  Our very brief -00 I-D gets us a foot in the door.  We also have some running code, and I've just updated some raw-text outlines of what to sort out next:

https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/ELR%20Proposal%202%20(AQM).txt
https://github.com/dtaht/bufferbloat-rfcs/blob/master/sce/ELR%20Proposal%203%20(TCP).txt

As noted in the latter document, a slightly modified version of DCTCP fits into this framework just fine without the compatibility problems that it has in L4S, and it would be possible to use AccECN for SCE feedback (though a rearrangement of the data fields could make it more efficient).  I'm not entirely happy with AccECN, so I've proposed several alternatives as well, including two that do not require standardising a new TCP option and thus might be easier to deploy.

 - Jonathan Morton