Re: [tsvwg] L4S vs SCE

Kyle Rose <> Wed, 20 November 2019 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BADDB1208EE for <>; Wed, 20 Nov 2019 02:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o-OTjSjUn_FO for <>; Wed, 20 Nov 2019 02:13:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::b31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5C8B1208EA for <>; Wed, 20 Nov 2019 02:13:54 -0800 (PST)
Received: by with SMTP id v2so9978736ybo.3 for <>; Wed, 20 Nov 2019 02:13:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=040VLAFy/AurlZxOmFaVRhxwvtcHeStjkmsXgYstdg8=; b=Hv8jjtje6whT9PTQkm7GDSQ0hZ81ENA0M9o4b29clPr9WKKvuapzjRBzasN6vL2fZc t8XvYRbqCHalSJ/0EFGw0zyXKrJRLVxLLMpgBd151oFBKfdCmji/eY1BTw/nntWfb0I5 UBitSS3FnbGxaE3ADETIWCtbkNCT5FeRpXJA4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=040VLAFy/AurlZxOmFaVRhxwvtcHeStjkmsXgYstdg8=; b=dHn/vTT4GpHhsDK17VQKRfqmeXfQYOnwFOsQw4SJjsF7PTPHdHMJVP6hjHox2E0ws9 uw21KwflwH+nR0V0S42C4t3wy1n7FRU8tKt3F1gZekiMj7aurS3t0mYDwcqbhyRFxR6f Zoqq8HWKBcVzujMGJYHCYmw11sf52in7Rqzzzq7GJNKVzB+G61IioKg5UST+2vt6bG1G 1sOA44bew35RTTFFHTxPd91tEqJzEC0nHCOK0JS99BHosS+yyHQKvpCXIcoQX0xrxWqC CIsjMwn0CBBxVWZ5EyIu2T4UP15mx6mIE54gcVuq9fpxrRI02Jb2aX3JmzzXObi6hcsx iXSw==
X-Gm-Message-State: APjAAAXn2jnA/XURgI5wMp0PjUtr30pxW38nKmkBqp1IAy3fvy8MtSPt hwahYE2b6krpXpB13mwvzoHmWkm2NX0GrOEekBcFIw==
X-Google-Smtp-Source: APXvYqx7zqjE3ChxVl1QbkuUdXOTPgv6JjThJ/xW3Xu8WeLAl4XR1iRNfUfG9EEkSV+eA7YWneHrlllE5h/UnqsSu7Q=
X-Received: by 2002:a25:d7cd:: with SMTP id o196mr1176021ybg.49.1574244833579; Wed, 20 Nov 2019 02:13:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Wed, 20 Nov 2019 18:13:41 +0800
Message-ID: <>
To: Ingemar Johansson S <>
Cc: Sebastian Moeller <>, G Fairhurst <>, "" <>, Ingemar Johansson S <>, "" <>, "De Schepper, Koen (Koen)" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000186c0b0597c47087"
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: Wed, 20 Nov 2019 10:13:57 -0000

On Wed, Nov 20, 2019 at 6:04 PM Ingemar Johansson S <ingemar.s.johansson=> 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.