Subject: [tsvwg] I-D Action: draft-ietf-tsvwg-ecn-l4s-id-23.txt

From: [email-masked]
Date: Fri, 24 Dec 2021 06:05:04 -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           : Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
        Authors         : Koen De Schepper
                          Bob Briscoe
	Filename        : draft-ietf-tsvwg-ecn-l4s-id-23.txt
	Pages           : 64
	Date            : 2021-12-24

Abstract:
   This specification defines the protocol to be used for a new network
   service called low latency, low loss and scalable throughput (L4S).
   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.  L4S uses 'scalable' congestion control,
   which induces much more frequent control signals from the network and
   it responds to them with much more fine-grained adjustments, so that
   very low (typically sub-millisecond on average) and consistently low
   queuing delay becomes possible for L4S traffic without compromising
   link utilization.  Thus even capacity-seeking (TCP-like) traffic can
   have high bandwidth and very low delay at the same time, even during
   periods of high traffic load.

   The L4S identifier defined in this document distinguishes L4S from
   'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
   migration path so that suitably modified network bottlenecks can
   distinguish and isolate existing traffic that still follows the
   Classic behaviour, to prevent it degrading the low queuing delay and
   low loss of L4S traffic.  This specification defines the rules that
   L4S transports and network elements need to follow with the intention
   that L4S flows neither harm each other's performance nor that of
   Classic traffic.  Examples of new active queue management (AQM)
   marking algorithms and examples of new transports (whether TCP-like
   or real-time) are specified separately.

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

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

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

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

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 24 Dec 2021 15:31:21 +0000

Folks,

We just uploaded revisions of the three main L4S drafts, which wrap up 
all the changes that resulted from push-back to the previous changes 
made in response to the WGLC, plus some other things we noticed in the 
process. They have already been discussed on the list unless stated 
otherwise below.

Here's a summary of the changes for each draft (I've quoted all three 
new version notifications below as well for convenience):

draft-ietf-tsvwg-ecn-l4s-id-23
* New 'MUST' to make detection as well as monitoring mandatory (§4.3, 
item 3)
    I introduced this on the list yesterday 
<https://mailarchive.ietf.org/arch/msg/tsvwg/IYc_624bFhRlp3qw2HahFb0sY_4/>, 
so not really enough time for discussion. But I've posting now, before I 
take a break.
* Changed from L4S AQM "SHOULD NOT smooth ... before signalling" to 
"MUST signal immediately" (§5.2 and §4.4)
     See posting [tsvwg] L4S ECN marking: MUST be immediate vs SHOULD 
NOT be delayed 
<https://mailarchive.ietf.org/arch/msg/tsvwg/0FKiKLC2Lm6W8_yRXW2HW7WadCw/>
* For inclusion of non-ECT packets in L queue, changed "MUST NOT alter 
non-ECN identifiers" to "MUST NOT alter Not-ECT or ECT(0)" (§5.4.1.1)
    For exclusion of L4S packets, expanded normative rule (§5.4.1.2)
    For both these, see posting [tsvwg] Changes to normative text in 
ecn-l4s-id as a result of WGLC 
<https://mailarchive.ietf.org/arch/msg/tsvwg/Yo69vUXpcuCVEq7orNGIDfOELw4/>
* Added or clarified some open questions, as suggested by Olivier 
Tilmans offlist (§7.1)
    (not discussed on the list)

draft-ietf-tsvwg-aqm-dualq-coupled-20
* On overload, changed from "Disable ECN marking" to "Introduce drop of 
ECT packets (while also still ECN-marking)" (§2.5.1 & §4.1.3)
     (not discussed on the list, but only a correction)

draft-ietf-tsvwg-l4s-arch-15
* On overload, changed from "Disable ECN marking" to "Introduce drop of 
ECT packets (while also still ECN-marking)" (§4.2).
     (for consistency with change to dualq-coupled above)
* human-readable identifiers for all references (the one point from 
Stuart's WGLC review that I deferred for later)
     See posting [tsvwg] start of WGLC on L4S drafts 
<https://mailarchive.ietf.org/arch/msg/tsvwg/FiWPi3WrIf9mYSth2AFSD3OrUXM/>

I believe that wraps up everything subsequent to the WGLC, except:
a) as I said, , given it's the holiday season, we need to give people a 
few days to respond to the first item above
b) David Black has said he wants to read the section about RFC4774 that 
was added to ecn-l4s-id at draft-22 (preview sent 4 Nov),... but it's 
now over 7 weeks since then??

Bob

On 24/12/2021 14:00, [email-masked] wrote:
> A new version of I-D, draft-ietf-tsvwg-aqm-dualq-coupled-20.txt
> has been successfully submitted by Bob Briscoe and posted to the
> IETF repository.
>
> Name:		draft-ietf-tsvwg-aqm-dualq-coupled
> Revision:	20
> Title:		DualQ Coupled AQMs for Low Latency, Low Loss and Scalable Throughput (L4S)
> Document date:	2021-12-24
> Group:		tsvwg
> Pages:		61
> URL:            https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-20.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-tsvwg-aqm-dualq-coupled/
> Html:           https://www.ietf.org/archive/id/draft-ietf-tsvwg-aqm-dualq-coupled-20.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-aqm-dualq-coupled
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-aqm-dualq-coupled-20
>
> Abstract:
>     This specification defines a framework for coupling the Active Queue
>     Management (AQM) algorithms in two queues intended for flows with
>     different responses to congestion.  This provides a way for the
>     Internet to transition from the scaling problems of standard TCP
>     Reno-friendly ('Classic') congestion controls to the family of
>     'Scalable' congestion controls.  These are designed for consistently
>     very Low queuing Latency, very Low congestion Loss and Scaling of
>     per-flow throughput (L4S) by using Explicit Congestion Notification
>     (ECN) in a modified way.  Until the Coupled DualQ, these L4S senders
>     could only be deployed where a clean-slate environment could be
>     arranged, such as in private data centres.  The coupling acts like a
>     semi-permeable membrane: isolating the sub-millisecond average
>     queuing delay and zero congestion loss of L4S from Classic latency
>     and loss; but pooling the capacity between any combination of
>     Scalable and Classic flows with roughly equivalent throughput per
>     flow.  The DualQ achieves this indirectly, without having to inspect
>     transport layer flow identifiers and without compromising the
>     performance of the Classic traffic, relative to a single queue.  The
>     DualQ design has low complexity and requires no configuration for the
>     public Internet.
>
>                                                                                    
>
>
> The IETF Secretariat
>
>

On 24/12/2021 14:03, [email-masked] wrote:
>          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-15.txt
> 	Pages           : 49
> 	Date            : 2021-12-24
>
> 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.
>
>
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-l4s-arch/
>
> https://www.ietf.org/archive/id/draft-ietf-tsvwg-l4s-arch-15.html
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-l4s-arch-15
>
>

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