Re: [tsvwg] L4S vs SCE

Markku Kojo <> Thu, 21 November 2019 01:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3B2A120900; Wed, 20 Nov 2019 17:43:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qfI1HJL6vNcP; Wed, 20 Nov 2019 17:43:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4E9C120903; Wed, 20 Nov 2019 17:43:53 -0800 (PST)
X-DKIM: Courier DKIM Filter v0.50+pk-2017-10-25 Thu, 21 Nov 2019 03:43:24 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date:from:to:cc:subject:in-reply-to:message-id:references :mime-version:content-type:content-id; s=dkim20130528; bh=xeuym1 Uqmf2qbh7Ay80az1wxeNqOe9ePIYn3Zdmn5r8=; b=Cr61OaD1ZiLTlKBpnJvLrK 9OhxBd9L+o2M0FaMxRGE/LC9vlXpRQ0jT7/iifGWs/g7z8PhskKNZlbdELPIGlqz tDb6xYd22mTrdZByRnIQIT8T2VKxfCs2AH4SFcEad1zq9qmaGWY1K7K3S64y4vPO HIBwd4pbSNMhltdTwWuak=
Received: from ( []) (AUTH: PLAIN kojo, TLS: TLSv1/SSLv3,256bits,AES256-GCM-SHA384) by with ESMTPSA; Thu, 21 Nov 2019 03:43:21 +0200 id 00000000005A0170.000000005DD5EBBA.00002FD8
Date: Thu, 21 Nov 2019 03:43:18 +0200 (EET)
From: Markku Kojo <>
To: "" <>
cc: Kyle Rose <>, Ingemar Johansson S <>, G Fairhurst <>, "" <>, "De Schepper, Koen (Koen)" <>, "" <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=_script-12865-1574300604-0001-2"
Content-ID: <>
Archived-At: <>
Subject: Re: [tsvwg] L4S vs SCE
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, 21 Nov 2019 01:43:56 -0000

On Wed, 20 Nov 2019, Kyle Rose wrote:

> On Wed, Nov 20, 2019 at 6:04 PM Ingemar Johansson S
> <> wrote:
>       >       How do you expect an industry/commercial roll-out of L4S
>       > technology to behave, if the L4S experiment should terminated without
>       > adoption as a standard track RFC? Are they supposed to phase-out using
>       > ECT(1) as well, or is it understood that deployed L4S instances continue using
>       > L4S methods?
>       [IJ] The premise would be that L4S is declared a failure. I doubt that anybody has
>       a good enough crystal ball to predict what happens. First it is necessary to come
>       to the conclusion that L4S is a failure and I would argue that we are not yet
>       there and I don't currently see that coming. Before that possible event I don't
>       see it meaningful to speculate.
> I'm going to have to go ahead and disagree with you strongly here. Given the potential
> consequences of cleaning up after a failed experiment without a plan worked out beforehand,
> this blithe approach is simply not acceptable.
> In lots of cases, experiments are easy to terminate in an obvious way: for example, in one
> typical case, a code point can simply be abandoned, or (even better) a pollutable experimental
> code point returned to the available pool after some time. If that were the case here, it
> would not be difficult to enumerate a sequence of steps required to do so. It doesn't appear
> that's the case, however, so all the more reason to make sure we address this as part of the
> experiment setup.
> A launch escape system of the necessary complexity should be a requirement of any experimental
> deployment. In this case, that might circumscribe the scope of the experiment itself.

I do not intend to speak out for either proposal but to raise my concern 
about future of new AQMs and related CCs that would really solve the 
problems that still seem to remain unsolved, particularly the problem of 
load transients such as flow startup. There have been a number of 
alternative proposals for ECN earlier and I expect there will be more in 
the future. I find it extremely important to allow such evolution.

That said, we have IETF-wide consensus documented in BCP 124 (RFC 4774) 
exactly for this case, i.e., the issues and requirements for a safe 
coexistence when defining alternate semantics for the ECN field. Sally, 
once again, has been very careful when considering the issues and the 
document is in most part very relevant. I would expect very thorough 
consideration for any deviation from the requirements in this document 
(along what is discussed in RFC 2914 and RFC 5033).

RFC 4774 also proposes a reasonable way forward for coexistence that is 
not necessarily ideal for widespread deployment in the global Internet 
but that's not what I find us discussing here. The question is about 
allowing controlled experiments in the Internet when using alternative ECN 
codepoint semantics for EXP purpose only. We very well know DSCP is known 
to have problems (bleaching, remarking, etc) but I don't think it would 
have that significant impact on EXPERIMENTING, because we have tools 
available to determine whether such problems are present in the 
end-to-end paths that are experimented with.