Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-l4s-arch-16.txt

From: [email-masked]
Date: Tue, 01 Feb 2022 14:36:36 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Area Working Group WG of the IETF.

        Title           : Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture
        Authors         : Bob Briscoe
                          Koen De Schepper
                          Marcelo Bagnulo
                          Greg White
	Filename        : draft-ietf-tsvwg-l4s-arch-16.txt
	Pages           : 49
	Date            : 2022-02-01

Abstract:
   This document describes the L4S architecture, which enables Internet
   applications to achieve Low queuing Latency, Low Loss, and Scalable
   throughput (L4S).  The insight on which L4S is based is that the root
   cause of queuing delay is in the congestion controllers of senders,
   not in the queue itself.  With the L4S architecture all Internet
   applications could (but do not have to) transition away from
   congestion control algorithms that cause substantial queuing delay,
   to a new class of congestion controls that induce very little
   queuing, aided by explicit congestion signalling from the network.
   This new class of congestion controls can provide low latency for
   capacity-seeking flows, so applications can achieve both high
   bandwidth and low latency.

   The architecture primarily concerns incremental deployment.  It
   defines mechanisms that allow the new class of L4S congestion
   controls to coexist with 'Classic' congestion controls in a shared
   network.  These mechanisms aim to ensure that the latency and
   throughput performance using an L4S-compliant congestion controller
   is usually much better (and rarely worse) than performance would have
   been using a 'Classic' congestion controller, and that competing
   flows continuing to use 'Classic' controllers are typically not
   impacted by the presence of L4S.  These characteristics are important
   to encourage adoption of L4S congestion control algorithms and L4S
   compliant network elements.

   The L4S architecture consists of three components: network support to
   isolate L4S traffic from classic traffic; protocol features that
   allow network elements to identify L4S traffic; and host support for
   L4S congestion controls.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4s-arch-16.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-l4s-arch-16

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 1 Feb 2022 23:45:19 +0000

tsvwg,

We've just updated the main 3 L4S drafts.

Diffs in l4s-arch-16 (relative to -15 that was posted on 24 Dec 21) are:
* Referenced ICCRG draft on BBR now that it documents v2, and took out 
commentary about BBRv1.
* Other references auto-updated

That's it.

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 Briscoe                               http://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 15 Feb 2022 21:29:54 +0000

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.
>

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