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

From: "Black, David" <[email-masked]>
Date: Tue, 1 Feb 2022 15:15:13 +0000

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: Stuart Cheshire <[email-masked]>
Date: Fri, 04 Feb 2022 16:22:20 -0800

> Thanks, --David, Wes & Gorry

I agree.

We should not delay RFC publication of the existing L4S drafts.

The drafts we have now are in good shape to publish, and doing that does not mean they are the final word on this topic. I hope and expect that we will have a decade of continued refinement in this area as we learn from experience and make futher improvements.

Stuart Cheshire

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 8 Feb 2022 15:10:17 +0000

I agree with the final conclusion. It is exactly in the spirit of how the draft is intended: open for AQM innovations. If you find a better AQM, try it, compare it with the reference implementations in the draft, and if it works better, use it (and let us know 😉).

Thanks,
Koen.

From: tsvwg <[email-masked]> On Behalf Of Black, David
Sent: Tuesday, February 1, 2022 4:15 PM
To: [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

---

From: Sebastian Moeller <[email-masked]>
Date: Tue, 8 Feb 2022 16:30:02 +0100

Dear chairs,

I would at least expect that the claims in the drafts are sufficiently toned down to reflect what the existing implementation actually delivers, and make it clear that anything above that is extrapolation and/or hope.
	ATM, what the drafts claim and what the existing implementation offers differ by a noticeable margin, if fixing the implementation before publishing the claims is ruled out (as it appears to be the case), then how about making sure the drafts do only promise what we know today to be reliably deliverable instead? It seems benign if future research shows that the drafts' claims and promises can be exceeded by better designs, but IMHO considerably less so if it turns out that current implementation is as good as it gets but the RFCs end up over-promising.

Sebastian Moeller

> On Feb 5, 2022, at 01:22, Stuart Cheshire <cheshire=[email-masked]> wrote:
>