Re: [tsvwg] FW: path forward on L4S issue #16

[Jonathan Morton <[e-mail]>]

> On 8 Jun, 2020, at 4:32 pm, Black, David <[e-mail]> wrote:
> 
> This TCP Prague work on bottleneck detection and problem avoidance has been going on for a year, and while it's produced some very interesting results and I'm sure that more progress will be made, I'm skeptical that relying on it to close issue #16 will yield much more than rounds of finding new problems in the next five versions of TCP Prague.   Beyond that, I'd expect to see quite a bit of L4S low latency traffic from protocols whose endpoint implementations have not been scrutinized to anything approaching the degree of attention that has been recently devoted to TCP Prague, and hence are at more risk of getting into trouble.

I think some concrete evidence of this possibility was provided by the experimental adaptation of SCReAM to use L4S signalling, which was discussed here fairly recently.  The implementation took a very bare-bones approach, copying only the use of the ECT(1) marker and the DCTCP response algorithm from whatever original source they used.  The result was summarily declared a success by its author without any analysis of how it might interact with conventional traffic; I assume he relied on the L4S team proper to have done their homework in that respect.

So we can indeed expect endpoints to behave like TCP Prague or like SCReAM, within the L4S ecosystem as presently defined.  Network operators will be expected to deal with the fallout.  I think we should also expect most network operators to be blissfully unaware of anything we're doing here; most, indeed, will be fully occupied in simply maintaining reliable connectivity to their own little patch of the Pacific, or Africa, or Asia Minor.

That is the context in which L4S must find a solution to proceed.  The solution must be demonstrated, tested, and documented in the appropriate drafts before it can be accepted.  I think it is a Hard Problem™, requiring genuine further innovation to solve - or, alternatively, a change to the signalling method in order to remove the ambiguity at the root of the problem.

 - Jonathan Morton