Re: [tsvwg] Dual-Q Polcing

[Jonathan Morton <[e-mail]>]

> On 27 May, 2020, at 5:41 pm, Gorry Fairhurst <[e-mail]> wrote:
> 
> I would generally encourage people to separate security considerations from congestion control/traffic sharing issues.
> 
> Reducing claims about performance/features in drafts is always welcome. For the WGLC, we need to finally balance protocol design goals, against claims of what is offered, and doing this before WGLC is generally helpful.
> 
> The WG Chairs and ADs have been discussing what topics should best be included in which documents. My own suggestion would be to allow a few weeks for the document editors to digest this and then propose what needs to be done in the next steps to take this forward.

Along these lines, these are the things I would expect to see addressed and considerably improved before a WGLC for L4S is even contemplated:

1: Interaction of minimally compliant L4S transport flows with existing network infrastructure and traffic.  This includes not only the incidence of single AQMs, but the relatively long paths and high jitter that exist in practice.  TCP Prague does not perform acceptably under these conditions, and neither does the proof-of-conceot adaptation of SCReAM to L4S-style signalling.

2: Performance of a minimally compliant L4S-aware middlebox under mixed traffic conditions, such that throughput of each class of traffic is "fair", under some widely accepted definition of "fair".  DualQ does not meet that standard.

3: Security and other operational considerations arising from the L4S specification, including the likely presence of bad actors.  These bad actors may ignore specifications entirely, or interpret specifications loosely, in an attempt to either gain an unfair advantage for their own traffic, or to disrupt service for others.  At the very least it is desirable to not worsen that situation; improving it is preferable if possible.

4: A sober and preferably independent appraisal of the actual performance obtained under varied conditions, for example according to RFC-5033.  Quoting from its introduction:

>    This document does not give hard-and-fast requirements for an
>    appropriate congestion control scheme.  Rather, the document provides
>    a set of criteria that should be considered and weighed by the IETF
>    in the context of each proposal.  The high-order criteria for any new
>    proposal is that a serious scientific study of the pros and cons of
>    the proposal needs to have been done such that the IETF has a well-
>    rounded set of information to consider.

The data thus far presented by the L4S team does not meet this standard, as it fails to cover scenarios that are less than ideal conditions for L4S, as demonstrated by the additional data provided by Pete Heist et al.

Personally, I am skeptical that L4S can meet these criteria without major architectural changes.  The most obvious of these would include a different use of the ECN field for congestion signalling (ie. not redefining CE, even conditionally).  The next most obvious would be to admit that L4S is not in fact suitable for widespread deployment on the public Internet, and instead confine it to specific networks that can be prepared for it; this would also permit using a DSCP as the classifier instead of ECT(1), freeing up the latter for alternative uses.

The onus is now on the L4S team to prove me wrong.

 - Jonathan Morton