Re: [tsvwg] Reasons for WGLC/RFC asap

Steven Blake <> Thu, 19 November 2020 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3DBC23A0FB1 for <>; Thu, 19 Nov 2020 10:41:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cNf2pp5x3ZsP for <>; Thu, 19 Nov 2020 10:40:59 -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 587713A0F9D for <>; Thu, 19 Nov 2020 10:40:58 -0800 (PST)
X-Sender-Id: totalchoicehosting|x-authuser|
Received: from (localhost []) by (Postfix) with ESMTP id 5133E401555; Thu, 19 Nov 2020 18:40:56 +0000 (UTC)
Received: from (100-96-227-237.trex.outbound.svc.cluster.local []) (Authenticated sender: totalchoicehosting) by (Postfix) with ESMTPA id 2C8AF401562; Thu, 19 Nov 2020 18:40:55 +0000 (UTC)
X-Sender-Id: totalchoicehosting|x-authuser|
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by (trex/5.18.10); Thu, 19 Nov 2020 18:40:56 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: totalchoicehosting|x-authuser|
X-MailChannels-Auth-Id: totalchoicehosting
X-Battle-Glossy: 3f10c7ff636294b3_1605811255978_2974569219
X-MC-Loop-Signature: 1605811255978:2028980916
X-MC-Ingress-Time: 1605811255977
Received: from [] (port=59214 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1kforT-0000L3-6v; Thu, 19 Nov 2020 13:40:51 -0500
Message-ID: <>
From: Steven Blake <>
To: Ingemar Johansson S <>, Lars Eggert <>
Cc: tsvwg IETF list <>
Date: Thu, 19 Nov 2020 13:40:53 -0500
In-Reply-To: <>
References: <> <> <> <>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.34.4 (3.34.4-1.fc31)
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] Reasons for WGLC/RFC asap
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, 19 Nov 2020 18:41:01 -0000

On Thu, 2020-11-19 at 09:43 +0000, Ingemar Johansson S wrote:
> Lars, Steven
> My opinion is that this work has stalled due to an endless discussion
> on the severity of the listed issues. Do you foresee that a year or
> so more of equally endless discussion will make anybody more wise ?,
> between meetings there are only a few people engaged in this debate
> that floods the TSVWG list, it is a safe bet that most outsiders hit
> the delete button.
> I can understand the incentives to try and delay WGLC/RFC, perhaps
> some hopes that there will by some magic emerge a much better high-
> fidelity congestion marking in some form. In short, tear the whole
> thing apart and come up with something much better. 
> The problem is that we are talking at least 2 years extra work to get
> into the state that the L4S drafts are today. 
> The use of the ECT(1) code point tend to often lead to questions like
> "what do we do when L4S fails?". Well the nonce has been declared
> historic so the process for this is in place, but besides this it is
> perhaps good to consider that L4S can actually fly ?. 
> I really think that it is high time to move this to WGLC, this has
> dragged on for too long. 

The objective should not be to produce documents. The objective should
be to produce *functioning technology*.

Are all of the component pieces of L4S functioning technology that can
be beneficially deployed in the Internet? Who knows? The simulation
results are inconclusive, at best.

What is the bare minimum that IETF needs to agree on to enable
interested parties to safely conduct and coordinate L4S *experiments*
in real networks? Focus on an answer to that instead of repeating sunk-
cost fallacies.


// Steve