Re: [tsvwg] closing L4S issue #17 on FQ interaction

[Greg White <[e-mail]>]

This seems to me to be a different issue than what was described in Issue 17 originally (which in my eyes was a concern that L4S flows would cause collateral damage to classic TCP flows in a cascading bottleneck topology).  So for clarity I think we should close Issue 17 and (if need be) track this separately.

This topic was discussed in comments 8-10 of Issue 17, https://trac.ietf.org/trac/tsvwg/ticket/17#comment:8. 
It is already included in the Issue 16 discussion as well.  Quoting from the Issue 16 tracker (https://trac.ietf.org/trac/tsvwg/ticket/16#comment:4 ):
"In its present form, an L4S sender made available for public testing reacts very slowly to congestion signals produced by existing Codel-family AQMs. Induced queuing delays reach approximately 125ms over a 10ms baseline RTT, and a standing queue persists for several seconds before being brought under control."

If we want to track this separately from Issue 16, then it should be its own Issue, as opposed to tracking it in the comments of Issue 17.

From what I've seen there are two concerns relating to RFC3168 bottlenecks. 
1. Single queue RFC3168 bottlenecks. These are presumed to be rare, but the concern is that L4S flows will cause competing classic flows to starve.  This is discussed in Issue 16.
2. FQ-CoDel RFC3168 bottlenecks (this issue). These are presumed to be more common than the single queue version, and the concern is that these bottlenecks will cause L4S flows to see greater latency than classic flows do.  A parallel concern is that these FQ-CoDel bottlenecks cause classic TCP to underutilize the link. As noted above, this is currently discussed in Issue 16 and the later comments in Issue 17.

The proposed solution for 1 is RFC3168 detection/fallback.  While I believe that RFC3168 detection/fallback could also address the latency concern in 2, a better (though longer-term) solution is to update FQ-CoDel bottlenecks (both to support L4S-style ECN marking, and to improve handling of classic TCP flows).  Since the solution space is a bit different between these two, perhaps that provides an argument for tracking them separately?

-Greg



On 2/5/20, 7:10 AM, "tsvwg on behalf of Jonathan Morton" <[e-mail] on behalf of [e-mail]> wrote:

    > On 5 Feb, 2020, at 4:00 pm, Wesley Eddy <[e-mail]> wrote:
    > 
    >> I have just added https://trac.ietf.org/trac/tsvwg/ticket/17#comment:10 to reflect my thoughts on this issue.
    > 
    > Thanks Jonathan; I have a quick follow-up question to make sure it's clear for the editors what their next steps should be.
    > 
    > Is it sufficient if they're adding an open issues / future work section to list this as an area for potential research and improvement with the experimental L4S deployments and transports being created for it based on TCP Prague requirements?
    
    No, I think this is fundamental enough (along with the closely related issue #16) to require a demonstrated working solution, rather than mere aspirations towards future research.
    
    SCE represents what such a demonstrated working solution might look like.  The difference is in the signalling mechanism, which remains RFC-3168 compatible by design.  L4S differs in this respect, which is why I consider it a fundamental design issue.
    
     - Jonathan Morton