Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim

Sebastian Moeller <> Thu, 12 March 2020 07:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C920F3A1281 for <>; Thu, 12 Mar 2020 00:52:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WhrknXU5Mg6H for <>; Thu, 12 Mar 2020 00:52:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9826C3A127F for <>; Thu, 12 Mar 2020 00:52:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1583999563; bh=fa8UOBkvaFQlmu1Ur9ow2EsMu4uNpxZPQDOhGfZXAys=; h=X-UI-Sender-Class:From:Subject:Date:References:To:In-Reply-To; b=KopRd8uXn1xUwpexeAv5SqV9GPENxE2IjwTZCwo9wWCKBI9z1pTfIjXJ1N+IRhdqh bRvrdpJ5JuCf//BaMeb90jZi/x2rAeQpkC26p9CanIbgkBCYk0vPUaS2RBQm9PBE9X ejbPce48L+ydkwbkK2Cfuxt80o8HIW/9J6mGpLEI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx004 []) with ESMTPSA (Nemesis) id 1MNKhs-1ixO7s3hNq-00OmiI; Thu, 12 Mar 2020 08:52:42 +0100
From: Sebastian Moeller <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Mar 2020 08:52:42 +0100
References: <> <> <> <> <>
To: tsvwg IETF list <>, Wesley Eddy <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:F8zLFw36QGqq5fT0Vzvc/xnpqa/ntY6a0VHxQBP9E9xBlYVqcnB THfk8tiqZ/Q5PmtuV3/J5+cLNEmmg84ESValPkM+H7Rk5QoPgIb38x9Tiu7JrOorUmJB0nf gOkVdfx4BLPwCrFm9bbtD199D+eSfltwJFbFOreQnEQtqcc/8gDSrTmvTDIDAs1Rs+GoHQ3 ebeGM/6IZJcMIIuE2Pehw==
X-UI-Out-Filterresults: notjunk:1;V03:K0:aDlx85dcuxU=:5x2404VeJfk5miYD53g2lA BDoVeZVEzJ6YWbJBKtkDyDIpMI+isdm1FB0rqicQ6mOqdwhaFTEYTd4GaLbwGp5mE5utWi0jv 9yff4BT7K+lQQYbSA+W0cgQQY4GYLS+QphqlhjHiBr2cxfnkfgpd6HftkQsFHtEqolx8kbdjS 7LD74I05yrFn/dRkB5MxxJW3uJ+opnZofIeZXVIJuEMfVAtqenyH43zVEV+7ky75h1sF50eRu 49XGyU3R9FB+p9rgRDmrIbO4ysxLWYjYivoIZbyH9dqALZhnwM6shcK+mA2DFxrDho2EH8uVt j+V9SZ+NE+C8KFFj7OSpzYYhl5ZwYhp5yAmPZHi5w54xvQMI3By0mnmSB37NvgEcb+xjQcbzn hGa/DO5rZHGB4PevLlcjvV5RF9hXfPeriJyziJheZMkF/frWT8/KnHjoy7ftkgMzTQ6fNIvjQ aXmPlQA3BX7z7EmRrcqQQ47EhvJQ1pYauNQSf/GCveTtchzhc7mKQPapONiAYYbr5q3Zue3tO b+9ieo9D9WP+NHC6PExXeKUblK4ztbwQQfcF1APLZPGarixCrGvd5VmpyJRa/5qnoAS7VUUrs QHiWwR3nWZuhK3yhloqKHZg74uMNVVaKeDXkakZKoMrPT80buB1iuIL6mVBkdawVYVLiOhB5j WTCfs8RUC3wgu+PRE1IZ9NrmkhSHPJsZPAYuEn5mRO1humxwWyePyOSqz2xWKknUtt/CBZ1c+ HaP3NvIPw9kgH/OzegjwLJSWl3Cw2rMNI1kU5cTnLpWdM4nXRdi8a9NCRQmptjc/VqR0peZw6 WncZe+9RgjHMRl2H/O21vNAmaf3BHeVg6zmNPYY6WCe5brCLs8hA+SDM9pGtackfUAoHtVzj0 iUZXVi8ujurY848jm6fRksYu/PgpxLioYmF3/KLJ0DiKCQIXIqH9aR89J8ekMPsr2jCHIB+A2 HvIlywKRe/KebHp5wpfWGjsEQkWyDySMT7r4/tZmn/AL/Zv2Azfif2/G7uea9URNxY1givhsV wm5edJ8V3ym3K6l2m8FloUkzjZBUE8YLkdt93sWAl1DTkxHenVumvPg0VXhLguobMrMrYTRe4 FBaq/JxamwzgOzL0kfvRyRXmDQYJ/QZ3FWBSsHzwplvaxvoD58ZIOANnYwuOEz5hjqIkwyXsH +B5uxXNn8trtgb/NMYRABKYDjxOnqjHi6F9mBjVJMQjcrP1US6xABTsOZiU/Qfz5M5mp472Z0 9reAKnv6p0NHDUAIh
Archived-At: <>
Subject: Re: [tsvwg] Follow-up to your DSCP and ECN codepoint comments at tsvwg interim
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: Thu, 12 Mar 2020 07:52:48 -0000

Hi Wes,

Thank you! More below in-line.... 

On March 11, 2020 4:50:01 PM GMT+01:00, Wesley Eddy <> wrote:
> On 3/9/2020 4:10 AM, Sebastian Moeller wrote:
>> QUESTION @Chairs: What are the conditions and aims for the TSVW WG in
> deciding to grant an RFC like L4S experimental status? I would love to
> get a clarification please.
> There are 3 chairs, and I only speak for 1, but the bottom-line is 
> simply "WG rough consensus" (decently described in RFC 7282).

	[SM] Oha, that RFC was in equal parts interesting, enlightening, and unhelpful ;) 

> Beyond that, I don't think we are adding or removing any explicit 
> criteria.  The RFCs on congestion control evaluation cover things that 
> have traditionally been of interest/concern to the community in 
> developing consensus that technologies were safe enough for
> experimental 
> deployment on the Internet.  In the case of the technologies that are 
> proposing to use ECT(1) for experiments today, I don't think this is
> any 
> different.

	[SM] I guess then I want to start a discussion about the starvation issue. RFC2914 about CC principles indicates strongly, that starving-out flows is unacceptable and equitable sharing of bandwidth (modulo some conditions) is desirable. But I will try to start that discussion in a separate thread about whether or not the current L4S implementation and design meets these principles sufficiently.

> As a chair, when sending to the IESG for recommended publication, I
> also 
> want to see that:
> (1) There is wide interest in deploying the technology.
> (2) The concerns with it are understood well enough to be considered by
> people deploying it, and they are aware of what they might want to 
> measure or what means are possible to mitigate problems.

[SM] Quite measured and convincing arguments.

> Sometimes the "experiments" don't clearly succeed (global deployment) 
> nor fail (nil deployment), but wind up very useful in some cases, and 
> not of interest in others.  In the case of ECT(1) (considered by itself
> without any DSCP-scoping), there probably should be some bit of a plan 
> or analysis around what happens if the technology persists in pockets 
> where it's useful, but doesn't have 100% deployment over the Internet. 
> We will need to consider the status of the ECT(1) codepoint, and how it
> can be used in the future whether these experimental specs are 
> successful (widely deployed), partially successful (deployed in 
> pockets), or failed (not deployed, or found defective and eventually 
> un-deployed).

[SM] That seems to acknowledge the fact that even a failed L4S experiment might spoil ECT(1) for a long time. This IMHO is supporting the idea that the experiment should only be started with mechanisms in place that allows a quick abort and recovery of ECT(1) on failure (given that there is an alternative proposal for ECT(1) usage in front of the WG). What are the technical arguments against rolling-out L4S experimentally in a cautious, measured safe and un-do-able way? The biggest arguments I hard so far were convenience (don't want to do more work than necessary) and easy of internet-wide deployment. IMHO the first is understandable but weak, while the second seems rather pre-mature given that L4S experiment and L4S as a a standard can be deployed using quite different methods and restrictions (so experiment under strict control and safety mechanisms and on success deployment under relaxed conditions seems like the obvious strategy).
Especially since the core questions L4S as an experiment is supposed to answer are a) will the positive lab-results also transfer into and materialize in the real-world  internet (functionality) and b) will they do so in a safe and compatible way with the existing internet (safety). 

Best Regards