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

[Wesley Eddy <[e-mail]>]

(I'm at least for now ignoring the parts of this not related to this 
thread on issue #16.)

On 6/17/2020 3:25 PM, Sebastian Moeller wrote:
>> (and if more emerge, they can be dispositioned and added if needed).  This particular thread is about agreeing on a path forward on the one labelled "issue #16" in the tracker.  Suggestions and discussion about that are good and welcome; repeatedly accusing others of bad intentions is not.
> 	[SM] In the spirit of progress, how about team L4S either accepts rfc3168 compatibility to be a hard requirement and we start to discuss what kind of properties the L4S solution needs to achieve (degree of flow imbalance, temporal fidelity of the detection, false negative rates, ...) or team L4S lays out a plan how to assess the position Ingemar (and Bob in the past) seem to take that rfc3168 AQMs are sufficiently rare in the real world to allow ignoring them. I would expect that we then discuss how to measure this** and decide on what thresholds we consider for significance before hand.

This is already a requirement.  In the L4S I-D draft, there is a 
requirement:

A.1.4 Fall back to Reno-friendly congestion control on classic ECN
           bottlenecks

    Description: A scalable congestion control needs to react to ECN
    marking from a non-L4S, but ECN-capable, bottleneck in a way that
    will coexist with a TCP Reno congestion control [RFC5681].

Again, the point of this thread is to figure out what the working group 
needs to do to achieve this.  Looking at it as a co-chair, I'm seeing 
basic agreement that the classic bottleneck detection algorithm will 
likely never be perfect.  I don't think there's agreement (or even very 
specific suggestions) about how good it needs to be.  There might be 
agreement that in any case, operators should not expect that all flows 
using ECT(1) will succeed in being nice to classic flows.  Along the 
lines of some of Paul Vixie's comments in earlier threads, protection 
from unfriendly or lying flows is important, and this should be true 
even without regard to whether an operator deploys L4S in their network, 
or if traffic is using ECT(1).  David has suggested to focus on 
operational guidelines that would help to avoid ECT(1) bleaching, and I 
think many agree that such bleaching would be undesirable.

So, it seems at the moment like we should be working on this in parallel 
to any improvements on classic bottleneck detection, because it will be 
important in any case.