Subject: [tsvwg] New revs of 3 main L4S draft following interim mtg

From: Bob Briscoe <[email-masked]>
Date: Fri, 4 Mar 2022 23:18:11 +0000

Wes as doc shepherd, and tsvwg list,

We've just posted new revs of the three main L4S drafts.
This follows the earlier posting to the list (pasted below)  warning of 
these upcoming changes.
We've also added some more clarifications, mostly pointed out via Koen's 
final review of the DualQ text.

Here's a summary of the diffs.

    ==l4s-arch-17==

      Technical/Editorial

* Delete Appendix A "Standardization items", which is an unmaintained 
ToDo list of potential IETF drafts from when L4S was first proposed.

      Editorial

* Gave English descriptions of references that might not be recognizable 
to a general reader, especially once drafts become just RFC numbers.
* Added ref to BBRv2 code
* Other minor nits
* Added author funding ACK.

    ==ecn-l4s-id-25==

      Technical/Editorial

* §4.3.1: Added that Alt ECN Semantics [RFC4774] did not foresee FQ as a 
potential method for isolating alt ECN behaviours.

      Editorial

* §4.3.1:  s/coexist within/be in/ regarding per-flow-queues
* Thru'out: Gave English descriptions of references that might not be 
recognizable to a general reader, especially once drafts become just RFC 
numbers.
* Thru'out: Added ref to BBRv2 code
* Thru'out: Other minor nits
* Added author funding ACK.

    ==dualq-coupled-ecn-22==

      Normative

* Clarified normative requirement about overload:

    If the DualQ Coupled AQM has detected overload, it MUSTbegin using  *introduce*
    Classic drop*to both types of ECN-capable traffic*,  
    and continue  until the overload episode has subsided.
    Introducing drop if ECN marking is persistently high isrequired  *recommended*  by
    Section 7 of [RFC3168] and Section 4.2.1 of [RFC7567].

      Technical

* DualPI2 pseudocode in Figure 8 omits a long-standing change to the 
Linux overload code (as warned in previous email quoted below).

    1:  dualpi2_update(lq, cq) {                % Update p' every Tupdate
    2a: if ( cq.byt() > 0 ) 2b: curq = cq.time() %use queuing time of 
first-in Classic packet 2c: else % Classic queue empty 2d: curq = 
lq.time() % use queuing time of first-in L4S packet
    *2a: curq = max(cq.time(), lq.time()) % use greatest queuing time*

* Altered walk-through text accordingly as well (as warned in previous 
email quoted below).

      Technical/Editorial

* New section:
*4.1.  Low Delay without Requiring Per-Flow Processing*
     Contains text motivating the DualQ pulled in from l4s-arch that was 
previously either not in the DualQ draft, or scattered in the Security 
Considerations subsections.
* Changed section heading:
     4.1.*2.*  Handling *Unresponsive Flows and *Overload
* and added roadmap to section
* New section:
*    4.2.1. Unresponsive Traffic without Overload*
     2 paras summarizing the goal of "no worse than single-queue AQM", 
and explaining why it happens
     Reason: Realized discussion of this topic had been discussed many 
times on the list, but never written into the draft.
* Altered section applicability to short-term starvation:
     4.1.1.*2.***2.** Avoiding *Short-Term* Classic Starvation: 
Sacrifice L4S Throughput or Delay?
     And altered the text accordingly.
     Reason: Recent list discussion showed applicability isn't clear
* Changed section heading
     4.1.2.*2.***2.** Congestion Signal *L4S ECN* Saturation: Introduce 
Drop or Delay?
     Clarifications, and clarified applicability as persistent saturation.
     Reason: Noticed incorrect definition during review.
* Changed section heading
     4.2.3.1.  Protecting against *Overload by* Unresponsive ECN-Capable 
Traffic
     Made the scenario clearer, and introduced the DualPI2 case as an 
example, explaining it more fully.
     Reason: To reflect explanations needed in recent list discussion

      Editorial

* Gave English descriptions of references that might not be recognizable 
to a general reader, especially once drafts become just RFC numbers.
* Added ref to BBRv2 code
* Other minor nits
* Added author funding ACK.

Bob, Koen & Greg

On 15/02/2022 21:29, Bob Briscoe wrote:
> tsvwg,
>
> The authors have noticed some further edits are needed since the 3 
> main L4S drafts were updated on 1 Feb 22 to pick up straggling WGLC 
> issues.
> So we plan to post another round of edits to all three drafts shortly.
> They are listed below so any concerns or questions can be picked up 
> before we go ahead.
>
> You will need an HTML mail reader.
>
>
>       l4s-arch
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-l4s-arch#appendix-A
> Delete Appendix A "Standardization items", which is an unmaintained 
> ToDo list of potential IETF drafts from when L4S was first proposed.
>
>
>       ecn-l4s-id
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-24#section-4.3.1
> Editorial change in §4.3.1:
>             o  With per-flow-queuing, co-existence between Classic and
>                 L4S flows is not normally a problem, because different
>                 flows are not meant tocoexist within  *be in*  the same queue,
>
>              o  However, the isolation between L4S and Classic flows is
>                 not perfect...
>
>
>       aqm-dualq-coupled
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-21#section-2.5.1.1
> Clarified normative requirement about overload:
>     If the DualQ Coupled AQM has detected overload, it MUSTbegin using  *introduce*
>     Classic drop*to both types of ECN-capable traffic*,  
>     and continue  until the overload episode has subsided.
>     Introducing drop if ECN marking is persistently high isrequired  *recommended*  by
>     Section 7 of [RFC3168] and Section 4.2.1 of [RFC7567].
>
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled-21#appendix-A.2
> Non-normative technical change: DualPI2 pseudocode in Figure 8 omits a 
> long-standing change to the Linux overload code.
>     1:  dualpi2_update(lq, cq) {                % Update p' every Tupdate
>     2a: if ( cq.byt() > 0 ) 2b: curq = cq.time() %use queuing time of 
> first-in Classic packet 2c: else % Classic queue empty 2d: curq = 
> lq.time() % use queuing time of first-in L4S packet
>     *2a: curq = max(cq.time(), lq.time()) % use greatest queuing time*
>
>
>     Lines  2ac to 2d  in the core PI algorithm (Figure 8) deal*s*  with overload
>     of the L4S queue when there is*little or*  no Classic traffic.  This is
>     necessary, because the core PI algorithm maintains the appropriate
>     drop probability to regulate overload, but it depends on the length
>     of the Classic queue.  If there is*little or*  no Classic queue, the
>     naive PI update function in Figure 6 would drop nothing, even if the
>     L4S queue were overloaded - so tail drop would have to take over
>     (lines 2 and 3 of Figure 3).
>
>     Instead,the test at line 2a of the full PI update function in Figure 8
>     keeps delay on target using drop. If the test at line 2a of Figure 8 
> finds that the Classic queue is empty, line 2d measures the current 
> queue delay using the L4S queue instead. While the L4S queue is not 
> overloaded, its delay will always be tiny compared to the target 
> Classic queue delay. So p_CL will be driven to zero, and the L4S queue 
> will naturally be governed solely by p'_L from the native L4S AQM 
> (lines 5 and 6 of the dequeue algorithm in Figure 7). But, if 
> unresponsive L4S source(s) cause overload, the DualQ transitions 
> smoothly to L4S marking based on the PI algorithm.*ensures that t***he base PI AQM in line 3 is driven by whichever of the two queue 
> delays is greater*, but line 3 still always uses the same Classic 
> target (default 15 ms). I***f L queue delay is greater just because there is little or no 
> Classic traffic, normally it will still be well below *the base AQM 
> target. This is***because L4S traffic is also governed by the shallow threshold of its 
> own native AQM* (lines 5a to 6 of Figure 7). So***the base AQM will be driven to zero and not contribute*. However, if 
> the L queue is overloaded by traffic that is unresponsive to its 
> marking, the max() in line 2 enables the L queue to smoothly take over 
> driving the base AQM into overload mode even if there is little or no 
> Classic traffic. Then the base AQM will keep the L queue to the 
> Classic target (default 15 ms) by shedding L packets. *
>
>
> Bob and co-authors
>
>
> On 01/02/2022 23:45, Bob Briscoe wrote:
>> tsvwg,
>>
>>
>> After consulting with Wes, I meant to delete Appendix A which is a 
>> ToDo list of IETF drafts from when L4S was first proposed. I'll take 
>> this opportunity to ask the list if there are any objections first. 
>> If not, I'll remove it at the next rev.
>>
>> Full diff available via the link below.
>>
>> Cheers
>>
>>
>>
>> Bob
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Wesley Eddy <[email-masked]>
Date: Wed, 9 Mar 2022 12:37:20 -0500

For anyone who was expecting edits based on their working group last 
call comments and discussion, please take a moment to check out these 
drafts in the next couple of weeks.