Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Jonathan Morton <[e-mail]>]

> On 10 Mar, 2021, at 10:20 am, Ingemar Johansson S <[e-mail]> wrote:
> 
> I most certainly hope that we don't spend valuable meeting time on
> discussing the real or imagined merits with SCE. 
> 
> If you find that specs are unclear as to how enable L4S support in Linux
> kernels and elsewhere, including how to navigate around the RFC lingo, then
> please point out where to fix this. A good starting point is the L4S Ops
> draft.

We have already been running tests using the published L4S kernel, as was discussed at previous meetings.  Here are some results we added recently, and mentioned in my talk on Monday:

	https://github.com/heistp/l4s-tests/#harm-to-flow-completion-time

> Like things are now my only interpretation of the situation is that you
> place your bets on that L4S will fail and you do your best to make this
> failure happen. For instance you point out a problem with fq-codel and L4S
> but show little interest or even oppose solutions to have this issue
> remedied. Please prove me wrong.

The reason we oppose L4S is because we believe it constitutes a danger to the Internet.  That was the thrust of my talk on Monday, supported by data collected recently by Pete and previously by Jake.

The reason I, personally, will not attempt to take pre-emptive actions to "enable" L4S deployment is because I have no desire to make that danger more likely to occur, nor to make deployment of less harmful alternative more difficult.  I consider it likely that upstream kernel maintainers would also reject such actions, were I to propose patches, on the grounds that they reduce compliance with existing published RFCs.  I have already explained this clearly.

We have proposed two methods of eliminating the problems with L4S.  One of them is SCE, first introduced almost exactly two years ago, which has running code that is ready to try out (in the lab) by anyone so inclined.  The other one is similar to SCE, but preserves the "classifier" input in the ECN field; it will require more handshake negotiation than SCE as a result, and has not been developed in detail.

The major benefit of both these proposals is that they shift the risk from "innocent bystanders" to "involved participants" by explicitly prioritising compatibility with existing networks, and only triggering the new congestion responses when a new-type AQM explicitly identifies itself as controlling the bottleneck on the path.  This benefit is not identified or discussed in the L4S drafts' appendices discussing these proposals, which is what prompted the topic of my talk on Monday.

Yet both of these proposals have been rejected outright by the L4S team and their allies, and there has been very little net technical change in L4S since we appeared on the scene.  This is despite changes in the existing Internet environment apparently refuting some of the assumptions that drove certain L4S design decisions.

Honestly, we believe the WG is wasting its time with further discussion of L4S per se, but it's up to the Chairs and the WG at large to make that determination.  I will read the l4s-ops draft again and see whether it approaches adequacy.  If it does not, then I will oppose its adoption and explain why.  It's the only ethical thing I can do here.

 - Jonathan Morton