Re: [tsvwg] start of WGLC on L4S drafts

[Bob Briscoe <[e-mail]>]

Phil,

On 26/08/2021 09:08, 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>.

    [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-
               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]> On Behalf Of Wesley Eddy
>> Sent: 29 July 2021 17:18
>> To: [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
>> .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
>> .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
>> .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/