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

From: Wesley Eddy <[email-masked]>
Date: Tue, 4 Feb 2020 10:40:10 -0500

It looks like we have mostly converged on the L4S issue tracker entry 
for FQ interaction:

https://trac.ietf.org/trac/tsvwg/ticket/17

Greg's last comment there sums it up well, I think.  Based on the 
threads and meeting notes, I'm not sure if anything specific needs to be 
done to the L4S drafts, other than making sure that the TCP Prague 
discussion there reflects what the testing has revealed is important to 
be done.

So, I think when the drafts are updated, we will be able to close this 
issue.  Please correct if this is wrong.

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 5 Feb 2020 04:56:05 +0200

> On 4 Feb, 2020, at 5:40 pm, Wesley Eddy <[email-masked]> wrote:
> 
> It looks like we have mostly converged on the L4S issue tracker entry for FQ interaction:
> 
> Greg's last comment there sums it up well, I think.  Based on the threads and meeting notes, I'm not sure if anything specific needs to be done to the L4S drafts, other than making sure that the TCP Prague discussion there reflects what the testing has revealed is important to be done.
> 
> So, I think when the drafts are updated, we will be able to close this issue.  Please correct if this is wrong.

I have just added https://trac.ietf.org/trac/tsvwg/ticket/17#comment:10 to reflect my thoughts on this issue.

 - Jonathan Morton

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 5 Feb 2020 09:00:12 -0500

> 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?

---

From: Jonathan Morton <[email-masked]>
Date: Wed, 5 Feb 2020 16:10:32 +0200

> On 5 Feb, 2020, at 4:00 pm, Wesley Eddy <[email-masked]> wrote:
> 
> 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

---

From: Luca Muscariello <[email-masked]>
Date: Wed, 5 Feb 2020 15:12:41 +0100

On Wed, Feb 5, 2020 at 3:00 PM Wesley Eddy <[email-masked]> wrote:

> discussion there reflects what the testing has revealed is important to be
> done.
> >>

Reading the discussion on the issue tracker I'm unable to understand
if the issue is fixed or there is a fundamental problem that can
happen in the wild. It looks like closely related to issue #16
with mitigation in presence of FQ.

Luca

---

From: Greg White <[email-masked]>
Date: Wed, 5 Feb 2020 21:08:06 +0000

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

    

     - Jonathan Morton