Re: [tsvwg] L4S operational guidance draft

[Jonathan Morton <[e-mail]>]

> On 16 Nov, 2020, at 8:31 pm, Wesley Eddy <[e-mail]> wrote:
> 
> In today's meeting, it was mentioned that the L4S operational guidance draft is part of the "safety case" for advancing other L4S drafts.  It's not as mature as the other docs yet (e.g. there are several"TODO" portions), but we want to understand if people think it's going in the right direction and will be suitable for this purpose as it's sketched, or what else should be added/changed/etc.
> 
> This is on the agenda for Wednesday's meeting.
> 
> So, if you have bandwidth, please check out the L4S operational guidance draft prior to the Wednesday meeting, so that we can get a better sense of how to proceed:
> 
> https://datatracker.ietf.org/doc/draft-white-tsvwg-l4sops/

My impression is as follows:

1: The draft is clearly incomplete.  Even if it is filled in tonight or tomorrow, we will not have time to evaluate it in a completed state before Wednesday.  That seems to be acknowledged, but I want it to be crystal clear in advance.

2: Much of the draft is about preparing a network specifically to handle L4S traffic.  The need to do this is a well-established weakness of L4S.  Unfortunately, endpoints cannot reliably determine whether the path they wish to communicate across consists entirely of L4S-aware networks.  Even after they begin communicating, the network does not unambiguously inform them of this fact, either positively or negatively.

3: The rest of the technical requirements in the draft talk about what happens when L4S traffic encounters the boundary of the specially-prepared network, and how to get it between two such networks without exhibiting non-standard behaviour while traversing the standard network in between.

I will not comment on the likely sufficiency of these measures, in both #2 and #3 categories above.  Instead I would like to highlight the basic intent of the draft, which appears to be as follows:

*** L4S traffic MUST be confined to networks that have been specifically prepared to handle it. ***

But this is the same situation that DCTCP has been in from the start, and which L4S was supposed to fix.  The only advantage that L4S now brings to the table is that AIAD traffic is identifiable as distinct from AIMD traffic, and can thus be directed into a separate queue with a specially tuned AQM.  That could have been the work of seven hours with mostly existing tools, not seven years.

Also, if L4S traffic is indeed confined to specially prepared networks, then one of those preparations could be to ensure that a DSCP identifying L4S traffic will survive end-to-end.  This would obviate the main reason for choosing ECT(1) as that identifier, and free up ECT(1) for other proposals that do not sacrifice interoperability on the public Internet.

If I am wrong about the above, then I would appreciate a clarifying discussion on the matter.  Otherwise, the above is the position I'm likely to take on Wednesday.

 - Jonathan Morton