Subject: Re: [tsvwg] L4S: AQM Algorithm Choice Issues (2)

From: Greg White <[email-masked]>
Date: Tue, 1 Feb 2022 19:19:23 +0000

David,

Thank you for continuing to facilitate progress to RFC publication for the L4S drafts.  While I think the importance of these remaining concerns also could be debated (I believe that they were presented as an individual’s viewpoint), I do agree with your conclusion that they can best be explored via experimentation.

Best Regards,
Greg

From: tsvwg <[email-masked]> on behalf of David Black <[email-masked]>
Date: Tuesday, February 1, 2022 at 8:15 AM
To: "[email-masked]" <[email-masked]>
Subject: [tsvwg] L4S: AQM Algorithm Choice Issues (2)

With many of the smaller L4S WGLC concerns having been dealt with via draft updates, the WG Chairs are starting to work through the larger concerns.  David Black's slides on this topic from IETF 111 (https://datatracker.ietf.org/meeting/111/materials/slides-111-tsvwg-sessb-31-a-l4s-issues-00 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-tsvwg-sessb-31-a-l4s-issues-00__;!!LpKI!zVBRipbLjaAbYig1ZebG8gLPYfURQ9_feiG5u8XtqBrgoEcpPeRPs3Di5te1z0pk$>) are a useful starting point – WG rough consensus will need to be reached on at least these concerns, and there may be additional concerns.

This message addresses the two concerns at the end of those slides, as stated in the last two main bullets on slide 2:
• AQM disadvantages fragmented and small-MTU traffic
• Congestion marking algorithm biased against small packets
• DualQ AQM algorithm intolerant of bursty traffic
• Bursty applications (e.g., real-time video) and links (e.g., WiFi) cause large reduction in goodput

These two concerns are specific to the aqm-dualq-coupled draft, as they concern the details of the AQM algorithm used in the DualQ[ueue] Coupled structure, specifically PI (in the form of PI2), and not the overall DualQ Coupled structure (which is the subject of other concerns in the IETF 111 slides).  The DualQ Coupled structure does not require use of the PI2 algorithm, as Appendix B of the aqm-dualq-coupled draft describes the use of the Curvy RED algorithm, and other AQM algorithms, e.g., CoDel, could be used.  Hence these concerns do not apply to the other two L4S drafts.

The WG chairs believe that the appropriate path forward for these two concerns is design, modification and experimentation with different AQM algorithms in the DualQ Coupled structure, e.g., a DualQ Coupled AQM based on CoDel, and hence the chairs believe that these concerns are not reasons to avoid experimentation with DualQ Coupled AQMs, e.g., the Dual Q Coupled PI2 and Curvy RED algorithms described in Appendixes A & B of draft-ietf-tsvwg-aqm-dualq-coupled.  Publishing the aqm-dualq-coupled draft as an Experimental RFC supports AQM design, modification and experimentation, making these concerns are suitable for resolution via experimentation, so they are not blocking issues for Experimental RFC publication of the aqm-dualq-coupled draft.

Thanks, --David, Wes & Gorry
TSVWG WG chairs

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 1 Feb 2022 22:05:54 +0000

+1 (time to move to experimentation – learning by doing – running code and all that)

From: tsvwg <[email-masked]> on behalf of Greg White <[email-masked]>
Date: Tuesday, February 1, 2022 at 14:19
To: "Black, David" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [tsvwg] L4S: AQM Algorithm Choice Issues (2)

David,

Best Regards,
Greg

---

From: Sebastian Moeller <[email-masked]>
Date: Wed, 2 Feb 2022 09:27:08 +0100

> On Feb 1, 2022, at 20:19, Greg White <[email-masked]> wrote:
> 
> David,
>  

	[SM] Yes, but that experimentation should have been performed before requesting permit to deploy something untested onto the existing internet

Here are two question for the "the experiment should happen after IETF RFC-ificaton" proponents:

1) Which experiments along a prepared/controlled network path with informed consenting voluntarily participating end-points could not have been done without the drafts reaching RFC status?

2) If you plan to perform experiment over uncontrolled path with uninformed and not willingly participating end-points how do you envision to get data on whether your end to end congestion methods works as desired/intended? 

Regards
	Sebastian

> With many of the smaller L4S WGLC concerns having been dealt with via draft updates, the WG Chairs are starting to work through the larger concerns.  David Black's slides on this topic from IETF 111 (https://datatracker.ietf.org/meeting/111/materials/slides-111-tsvwg-sessb-31-a-l4s-issues-00 [datatracker.ietf.org]) are a useful starting point – WG rough consensus will need to be reached on at least these concerns, and there may be additional concerns.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 2 Feb 2022 09:58:14 +0000

> 2) If you plan to perform experiment over uncontrolled path with uninformed and not willingly participating end-points how do you envision to get data on whether your end to end congestion methods…

Thanks for letting the TSVWG know. Your position has already been noted 
during the WGLC and the consensus on publication will be discussed in 
the Document Shepherd wrietup.

Best wishes,

Gorry Fairhurst

TSVWG Co-Chair