[tsvwg] Summary of diffs in ecn-l4s-id-23, aqm-dualq-coupled-20, l4s-arch-15

Bob Briscoe <ietf@bobbriscoe.net> Fri, 24 December 2021 15:31 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28C63A0CFF for <tsvwg@ietfa.amsl.com>; Fri, 24 Dec 2021 07:31:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJqNu4CkxTqn for <tsvwg@ietfa.amsl.com>; Fri, 24 Dec 2021 07:31:26 -0800 (PST)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61D83A0CFD for <tsvwg@ietf.org>; Fri, 24 Dec 2021 07:31:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0Ew3GgHUQD2vscEgmc2WvuU8CD4z+onWAzeNBLgOfxc=; b=2+zhoPJLbSQKxR327bLNMcaJ3t DSr7c2GntEN4lZwti5RHnxiCoFq+d7DvpvwPgzaEBt9J6HJPVeY0LALX2Crp2XYUJA0OprZ4dEprJ rofxffCI01At4GnLbN+bFtrOY0HsPwq9R70d1MOEDbjddouejm71SdgP5gVDhIjCifhwSRAhIVKIN vjJW/V38lqtrvM5h5cFGQKi0pNlcTrCAYUh4EIZyKN+7bw7zRmycNZBYvJr5em1b9ZPrhu9RFiePP UK+4iIyEZjkajMLB0VTJsG0v3yuadGQCJ1rVFCt+1dfxZ1ZbExpllzPjvhhyHsW6piyJQo2tN5GQX Tlqd2jhQ==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:41564 helo=[192.168.1.11]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1n0mXb-0002Gi-Rd for tsvwg@ietf.org; Fri, 24 Dec 2021 15:31:23 +0000
To: tsvwg@ietf.org
References: <164035470481.26626.218904432277206168@ietfa.amsl.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <b76f9b96-51c4-5049-58d9-440fecdbc674@bobbriscoe.net>
Date: Fri, 24 Dec 2021 15:31:21 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <164035470481.26626.218904432277206168@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------5A602F63CD34343A77CC685A"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/1X3SDIH9h8vRh00BNlpzxHeHGXQ>
Subject: [tsvwg] Summary of diffs in ecn-l4s-id-23, aqm-dualq-coupled-20, l4s-arch-15
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Dec 2021 15:31:31 -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:05, internet-drafts@ietf.org wrote:
> 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
>
>


On 24/12/2021 14:00, internet-drafts@ietf.org 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, internet-drafts@ietf.org wrote:
> 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-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.
>
>
> 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-15.html
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-l4s-arch-15
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>


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