Re: [tsvwg] start of WGLC on L4S drafts

[[e-mail]]

Bob,
Thanks, the edits all look good to me
Best wishes
Phil

From: tsvwg <[e-mail]> On Behalf Of Bob Briscoe
Sent: 25 October 2021 21:05
To: philip.eardley=[e-mail]; [e-mail]; [e-mail]
Subject: Re: [tsvwg] start of WGLC on L4S drafts

Phil,
On 26/08/2021 09:08, philip.eardley=[e-mail]<mailto:philip.eardley=[e-mail]> wrote:

Some comments on the Architecture draft.



It is a nice document, thanks for all the work.

Some minor suggestions that I think are easy to resolve.



Section 1 Intro

Para 1- maybe some refs could be added, eg "spikes of hundreds of milliseconds are common"

[BB] That comes from a slow start of a short RTT flow in fast links with a state of the art AQM, which is generally tuned to respond over a max RTT (e.g. 100ms). Or multiple parallel flow starts. I've added a couple of references, which are the evaluations of the two main families of solutions prepared by those who developed them:
[COBALT] (which also compares with FQ_CoDel) and [DOCSIS3AQM] which evaluates CoDel, SFQ-CoDel and PIE.

   [COBALT]   Palmei, J., Gupta, S., Imputato, P., Morton, J.,

              Tahiliani, M., Avallone, S., and D. Taeht, "Design and

              Evaluation of COBALT Queue Discipline", In Proc. IEEE

              Int'l Symp. Local and Metropolitan Area Networks

              (LANMAN'19) 2019:1-6, July 2019,

              <https://ieeexplore.ieee.org/abstract/document/8847054><https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fieeexplore.ieee.org%2Fabstract%2Fdocument%2F8847054&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399543930%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Umg1zBPUtfhN1xgG4a%2BObyAH5c6KqHO2FWOz6eGE7bw%3D&reserved=0>.

   [DOCSIS3AQM]

              White, G., "Active Queue Management Algorithms for DOCSIS

              3.0; A Simulation Study of CoDel, SFQ-CoDel and PIE in

              DOCSIS 3.0 Networks", CableLabs Technical Report , April

              2013, <{http://www.cablelabs.com/wp<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cablelabs.com%2Fwp&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399553873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MEaSLe2%2F2r1ciG%2BVws4KKkB3gLqUA%2Fea06RKpp766pQ%3D&reserved=0>-

              content/uploads/2013/11/

              Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf>.

I think we'll need to temper "common" to "not uncommon" though, 'cos it's difficult to be sure how common the test scenarios are in practice.



and "queuing is typically configured to cause overall network delay to roughly double relative to expected base (unloaded) path delay."

[BB] "Roughly double" refers to the 1 BDP rule of thumb for buffer sizing in access links with low stat mux. I've cited the well-known SIGCOMM'04 paper on 'Sizing Router Buffers'. Altho this is primarily about why the rule does /not/ apply where flows are highly multiplexed (core networks), it starts by explaining the 1 BDP rule for access networks.




Section 2 L4S Architecture Overview

I think you could expand this section a little to provide a 'protocol model' (RFC4101: "to answer three basic questions:   1. What problem is the protocol trying to achieve?     2. What messages are being transmitted and what do they mean?     3. What are the important, but unobvious, features of the protocol?")

The intro does a good job of answering question 1.

For me, S2 should lay out (at a high-level) the solution. The current Section gives the 'components' without spelling out how they fit together, and also includes justification and background (about state of the art), which I think would be better to discuss separately. Also, it's stated that ECT(1) and CE are used, but not how. I think it would be good to include a figure here (Fig 1, or some version)

[BB] OK I've caved to your demands, esp. given I've batted off a number of similar comments in the past.

But first, I've added a Document Roadmap section at the end of the Introduction to explain that the way the document is written deliberately starts with assertion not explanation. Then the rationale follows later. Some readers prefer to just be told. Others prefer to know why. This serves both. It's done this way, because, if the reader doesn't have the whole picture, they can get lost in all the justification before the big picture has become clear.

Then I've started the Architecture Overview with a para that gives the 1-minute explanation based around the 3 parts.
Then I've changed the order of the 3 parts, to put the host first, 'cos scalable CC is the thing that creates the low latency. And I've moved the explanation of the problem with Classic and why scalable CC solves it from the terminology section to here.

I won't paste it all here, I'll post it in a few hours time anyway.

I haven't moved Fig 1 to here. Excuse: This is a symptom of the document having originally been written with the DualQ as /the/ architecture. Then we made FQ and DualQ equally important, but still had Fig 1 in this section to illustrate the DualQ side. Then we were asked to explain the DualQ and FQ solutions more fully (in §4.2) rather than relying on the dualq draft, and we were asked to move the DualQ figure down into §4.1.





Section 4.2

Fig 1

The '1' between the functions Mark and Scheduler could be explained?

[BB]
s/Then the scheduler can serve the L4S queue with priority/
  /Then the scheduler can serve the L4S queue with priority (denoted by the '1' on the priority input)/

That's common scheduler notation apparently.







I found S4.2 a bit hard to parse. I think my issue is that the intro para implies that bullets are about different per flow options. Bullets b and c are about this, but bullet a is (I think) a solution without per flow, and is actually the preferred approach. Bullet a also includes explanation of the dual queue that would apply to any solution.

Perhaps: re-write the intro para, especially delete the "Nevertheless" sentence, make bullet (a) main text and explain dual q etc. Then say there are different per flow options, and start bullet (a) by stating it is the option without per-flow.

[BB] OK, we had obviously confused you (so presumably others as well): I've added this sentence to introduce the table, and I've added a heading at the start of each bullet:

"The following bullets describe the known arrangements: a) the DualQ Coupled AQM with an L4S AQM in one queue coupled from a Classic AQM in the other; b) Per-Flow Queues with an instance of a Classic and an L4S AQM in each queue; c) Dual queues with per-flow AQMs, but no per-flow queues:"

I've also added a reference to the Linux patch that adds the necessary classification to the FQ_CoDel qdisc in order to implement (b).

BTW, there isn't a "preferred approach", from the IETF's point of view.






Section 8.3

Is "catastrophically" the best word?

[BB] Yes ;)

Thank you for all these. Some were quite hard, but necessary.

Cheers



Bob







Best wishes

Phil





-----Original Message-----

From: tsvwg <[e-mail]><mailto:[e-mail]> On Behalf Of Wesley Eddy

Sent: 29 July 2021 17:18

To: [e-mail]<mailto:[e-mail]>

Subject: [tsvwg] start of WGLC on L4S drafts



This message is starting a combined working group last call on 3 of the L4S drafts:



- Architecture:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf%2F&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399563827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=b%2FVGMG4fErHp9nUDEyOelTiiAu7lI1ce5RYGUY8t2bM%3D&reserved=0>

.org%2Fdoc%2Fdraft-ietf-tsvwg-l4s-

arch%2F&amp;data=04%7C01%7Cphilip.eardley%40bt.com%7Cb44881804bed467

1142f08d952ac8c68%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637

631723313409962%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ

QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=fATwA9c

bixSYOkh3vM2IugJ29oPEpvdgEIxbhAx6lMw%3D&amp;reserved=0



- DualQ:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf%2F&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399573785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J0PzmCZq%2FIRj8CvHjAv7IucZC0y3ZnO4%2B8lG5g9nG7k%3D&reserved=0>

.org%2Fdoc%2Fdraft-ietf-tsvwg-aqm-dualq-

coupled%2F&amp;data=04%7C01%7Cphilip.eardley%40bt.com%7Cb44881804bed

4671142f08d952ac8c68%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C

637631723313419949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL

CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=PR8Rj

3%2BmElcld7NBD7TxOgdkkvEyvbjda2qeUANy%2FAY%3D&amp;reserved=0



- ECN ID:

https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf<https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf%2F&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399573785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=J0PzmCZq%2FIRj8CvHjAv7IucZC0y3ZnO4%2B8lG5g9nG7k%3D&reserved=0>

.org%2Fdoc%2Fdraft-ietf-tsvwg-ecn-l4s-

id%2F&amp;data=04%7C01%7Cphilip.eardley%40bt.com%7Cb44881804bed46711

42f08d952ac8c68%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C63763

1723313419949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj

oiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oAg1Pi24Z

Uc4lZK9zwtXA95tm%2F%2B5Y9V2Fz8pEmBMv9g%3D&amp;reserved=0



The WGLC will last through 4 weeks from today, and then we'll see what to do

next.  Please submit any comments you have on these to the TSVWG list in that

timeframe.



The chairs are considering a possible virtual interim following the close in order to

work through feedback received.



The work on the L4S operational guidance draft is continuing in parallel, but that draft

is not being last called yet.







--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbobbriscoe.net%2F&data=04%7C01%7Cphilip.eardley%40bt.com%7Cc5762b3bea68444699cb08d997f2d052%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637707891399583744%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qSBGphsdXqw2IVawmmWOZ5AInFDNGKSkHladyJxfNQE%3D&reserved=0>