Re: [tsvwg] L4S Editorial Reviews (was: start of WGLC on L4S drafts)

[Bob Briscoe <[e-mail]>]

Mirja, see [BB] inline...

On 18/08/2021 09:41, Mirja Kuehlewind wrote:
>
> Hi Bob,
>
> see three replies below.
>
> *From: *tsvwg <[e-mail]> on behalf of Bob Briscoe 
> <[e-mail]>
> *Date: *Tuesday, 17. August 2021 at 18:01
> *To: *Mirja Kuehlewind <mirja.kuehlewind=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *Subject: *[tsvwg] L4S Editorial Reviews (was: start of WGLC on L4S 
> drafts)
>
> Mirja,
>
> Having said I would hold back replies, yours are fairly brief, so I'll 
> reply now...
>
> On 11/08/2021 14:57, Mirja Kuehlewind wrote:
>
>     Hi all,
>
>     I re-reviewed the drafts and support publication. A few editorial comments below.
>
>     Mirja
>
>     draft-ietf-tsvwg-l4s-arch - This purely editorial:
>
>     For me the main contribution of this work is nicely shown in Figure 1.  I recommend to add a similar, maybe slightly simplified figure at the beginning of section 2.
>
>
> [BB] Until draft-07, this figure was in Section 2. But we moved it to 
> the more detailed section on the DualQ when we also 'rebalanced' the 
> draft to make it clear that FQ-L4S is as much a part of the L4S 
> architecture as DualQ.
>
> Was your comment given with that in mind?
>
> [MK] This rebalance is fine but now it feels like there is a figure 
> missing in section 2. Therefore I proposed to _/also/_ add the figure 
> to section 2 but maybe a slightly simplified version without the 
> details of dualQ, e.g. just have some box that says “L4S-aware AQM” or 
> something. The important part would be to show the different 
> components (Scalable CC in the endpoint, 
> Identification/Classification, and AQM) and explain how the “work” 
> together.
>

[BB] OK, I'll try. This is going to be a pretty content-free diagram if 
it's going to cover both FQ & DualQ, 'cos there isn't much in common 
between them.

>
>
>
>     draft-ietf-tsvwg-ecn-l4s-id - nits:
>
>     - In the Intro there seems to be a missing word at the end of this sentence...?
>
>     " L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
>
>         layer that is similar to the original (or 'Classic') ECN approach,
>
>         except as specified within."
>
>
> [BB] That's OK in English. It just means similar to "as specified 
> below", but "below" tends to mean "immediately below".
>
> [MK] Actually looking at this sentence again, the whole sentence is 
> not super clear. I think rather than saying “it’s similar to classic 
> ECN except it’s not”, it would be better to say what is different. In 
> other words I would actually remove this sentence and rather say (at 
> the end of this paragraph) something like: “This draft specifies the 
> use of the ECN ECT(1) code point as an identifier for L4S traffic.”
>

[BB] The differences from RFC3168 are primarily the behaviour, which is 
what this draft mainly describes, not just the identifier.  But I've had 
previous resistance to saying it's similar to classic ECN, so I am going 
to have to improve it somehow (without making the abstract even longer). 
How about:

    An L4S sender sets the ECT(1) codepoint in the ECN field of the IP header to indicate
    that it is using an L4S congestion control. Then if there is Active Queue Management (AQM) that
    supports L4S on the path, it applies an L4S marking behaviour to such packets.
    The L4S protocol on the wire broadly follows the original (or 'Classic') ECN protocol, but this document
    defines both the transport layer behaviour and the network node behaviour needed to support L4S.


>     draft-ietf-tsvwg-aqm-dualq-coupled:
>
>     Should Figure 1 rather say L and C queue instead of L4S and Classic queue?
>
>
> [BB] I think it's useful to give the names in full in this figure, 
> isn't it? However, given it talks about the L queue and C queue below 
> that, I'll say
>     L4S (L) queue
>     Classic (C) queue
> OK?
>
> [MK] Section 2.3 says:
>
> „Thus, the L queue is not
>
>    solely an L4S queue, it can be consider more generally as a low
>
>    latency queue.“
>
> So my understanding was that L is actually an abbreviation for “low 
> latency” and “L4S”. However looking at the terminology it says:
>
> “L: Abbreviation for L4S, e.g. when used as a subscript.“
>
> I think this might need some clear up to get this straight.
>

[BB] Yes, this needs to be made consistent.

In ecn-l4s-id it says:

    In this case it would not be appropriate to call the queue an L4S
    queue, because it is shared by L4S and non-L4S traffic.  Instead it
    will be called the low latency or L queue.  The L queue then offers
    two different treatments:

    o  The L4S treatment, which is a combination of the L4S AQM treatment
       and a priority scheduling treatment;

    o  The low latency treatment, which is solely the priority scheduling
       treatment, without ECN-marking by the AQM.


In aqm-dualq-coupled under the definitions of the letters L and C, there 
is a sentence saying "Both Classic and L4S services can cope with a 
proportion of unresponsive or less-responsive traffic as well, ..."

I propose that
a) L always denotes 'low latency' more generally, not just L4S.
b) we use the term "non-congestion controlled low latency treatment" not 
just "low latency treatment" for the non-L4S treatment in the L queue.

I think I can then make everything consistent. I'll see whether this 
works when I actually edit it.

Thanks



Bob

>
> Mirja
>
>
>
>
>
>     On 29.07.21, 18:18, "tsvwg on behalf of Wesley Eddy"<[e-mail] on behalf of [e-mail]>  <mailto:[e-mail]@mti-systems.com>  wrote:
>
>          This message is starting a combined working group last call on 3 of the
>
>          L4S drafts:
>
>          - Architecture:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/  <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/>
>
>          - DualQ:
>
>          https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/  <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/>
>
>          - ECN ID:https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/  <https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/>
>
>          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 Briscoehttp://bobbriscoe.net/  <https://protect2.fireeye.com/v1/url?k=83fd01ee-dc66393c-83fd4175-866132fe445e-2ea15d5d62688d61&q=1&e=8f894785-ae8d-45d8-a094-22557c4afbba&u=http%3A%2F%2Fbobbriscoe.net%2F>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/