Re: [tsvwg] L4S drafts: Next Steps

Bob Briscoe <> Tue, 08 December 2020 23:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 01E003A1318 for <>; Tue, 8 Dec 2020 15:00:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CpUwPNN_xb6B for <>; Tue, 8 Dec 2020 15:00:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A36B3A12F3 for <>; Tue, 8 Dec 2020 15:00:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=/PujWNi8MTlGzHcvpCLjKO1Bq6GLKXTUzumrTapEPJE=; b=3Jo8Amcn3Q3aXH7J6C1ld3jIr HHBaNBlMBQky9vyVA6RuA+Z5Wbfu68cUejxNHd4BwMQKuTeEgfwLkMuWsxxhR9yV+i5WGzUeV+EJO BQBn2uJ6B3xogc2TGwC8YwdbZ9Rc7+CkJBTwhJT9O6uxq8647+prCDyL5gW56la3FQHjlCudtBOx8 hq0BRKzyuJmw6EgsOTveS/NV11+388bBZjTvBNDBW+ay6dTBP50ANUS4oUpBbyFHIDVN4DUorTaNQ 9Pe3YbUgl1x+BHd/to5ng++I4PXwhDs641wfKhydyGATLXXkXKTe6eHa78SUW40jeBFyzfHfTEMGF izgPn4bNA==;
Received: from ([]:54342 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1kmlyP-00HHh0-Us; Tue, 08 Dec 2020 23:00:46 +0000
To: "Black, David" <>, "" <>
References: <>
From: Bob Briscoe <>
Message-ID: <>
Date: Tue, 08 Dec 2020 23:00:44 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------BBF98A2AEF36BB1C72064966"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tsvwg] L4S drafts: Next Steps
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Dec 2020 23:00:57 -0000

David and chairs,

On 04/12/2020 15:54, Black, David wrote:
> The WG chairs have consulted among ourselves and with our AD (Martin 
> Duke).
> Our guidance to the WG and the L4S draft authors is that at least the 
> following two things need to be done before WGLC will become possible 
> on the L4S drafts:
> [1] Rework the “Prague Requirements” into the following two entities, 
> which will overlap:
> a.Transport-protocol-agnostic normative requirements for all 
> congestion-controlled traffic that uses the L4S low latency queue.
> ·The DualQ AQM design relies upon traffic adhering to these requirements.
> b.Design and implementation guidelines for new congestion controls 
> that meet the normative requirements (a).
> ·Ultimately, the choice of whether a particular aspect is a guideline 
> (b) or requirement (a) is a WG “rough consensus” decision.

[BB] I believe draft-ietf-tsvwg-ecn-l4s-id is already structured for 
this division between normative requirements and design and 
implementation guidelines.
* [1]a) is Section 4 "Prerequisite Transport Layer Behaviour". Nearly 
every paragraph also refers off to subsections of Appendix A.1 for extra 
non-normative info, headed "Requirements for Scalable Transport 
Protocols". [Actually, it might be useful to swap these two headings]
* [1]b) is Appendix A.2: "Scalable Transport Protocol Optimizations"

The rule that determined which aspect went in which was:
[1]a) if it's about an aspect of one transport's behaviour that has 
potential to impact/harm others
[1]b) if it's solely about how a transport can improve it's own performance.
They have been divided like that from the very first ad hoc meeting in 
Prague that formulated them (in 2015)

Code to address all the requirements and most of the optimizations has 
been implemented. Over the last year, 3 or 4 of the later requirements 
in a) have become SHOULDs not MUSTs. Personally I would have left most 
as MUSTs, but I've tried to reflect what the WG wanted. Those demoted to 
SHOULD have generally been considered a lower risk of harm (either low 
likelihood of occuring or minor harm if they do) - taking into account 
the complexity of implementing them.

We could certainly flag the point where the transition from MUSTs to 
SHOULDs occurs within section 4. But I think we should still group all 
the items with potential for harm together in the same section. Because 
assessment of risk will change as the Internet landscape changes 
(possibly over the duration of the experiment).

Now I've explained, I hope the chairs will all agree that "rework the 
Prague Requirements into two entities" (normative requirements and 
design and implementation guidelines) is already done and dusted.

Nonetheless, if there are specific items in S.4 that someone believes 
should or shouldn't be there, or should be worded differently, let's 
have those discussions now on the list - I'm all ears.


>      Success of this exercise will be judged by the WG reaching “rough 
> consensus” that multiple transport protocol implementations
>      currently meet and/or are reasonably expected to be able to meet 
> the normative requirements (a).
> [2] Build the safety case for L4S experimental Internet-wide 
> deployment in the L4S Ops draft.
> a.This safety case does not rely on endpoints running TCP Prague, 
> though it can assume endpoints are meeting the reworked Prague 
> requirements
> b.Ops draft will provide guidance on how to detect L4S problems on 
> their RFC 3168 network, and how to mitigate them.
> c.Ops draft must consider these scenarios:
> · An unsophisticated user purchases an L4S endpoint and runs it on a 
> service provider's single-queue RFC 3168 network.
> · L4S traffic from another domain enters an RFC 3168 single-queue 
> network (e.g. a peer-to-peer application)
>      Success of this exercise will be judged by the WG reaching “rough 
> consensus” that deployment of the L4S experiment
>      is unlikely to cause significant damage to the Internet, and that 
> any damage that results is expected to be tolerable.
> Thanks, --David [as TSVWG WG co-chair]
> ----------------------------------------------------------------
> David L. Black, Senior Distinguished Engineer
> Dell Technologies, Infrastructure Systems Group
> 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323 <tel:+17743509323>           Mobile: +1 (978) 
> 394-7754 <tel:+19783947754>
> <>
> ----------------------------------------------------------------

Bob Briscoe