Re: [tsvwg] Another tunnel/VPN scenario (was RE: Reasons for WGLC/RFC asap)

"Rodney W. Grimes" <> Thu, 03 December 2020 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA1003A0A2B for <>; Thu, 3 Dec 2020 09:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8zvUAeQ61SgC for <>; Thu, 3 Dec 2020 09:44:38 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8B5C3A0A26 for <>; Thu, 3 Dec 2020 09:44:38 -0800 (PST)
Received: from (localhost []) by (8.13.3/8.13.3) with ESMTP id 0B3Hhk6j061789; Thu, 3 Dec 2020 09:43:46 -0800 (PST) (envelope-from
Received: (from ietf@localhost) by (8.13.3/8.13.3/Submit) id 0B3HhiZ4061788; Thu, 3 Dec 2020 09:43:44 -0800 (PST) (envelope-from ietf)
From: "Rodney W. Grimes" <>
Message-Id: <>
In-Reply-To: <>
To: Gorry Fairhurst <>
Date: Thu, 03 Dec 2020 09:43:44 -0800
CC: Jonathan Morton <>, Bob Briscoe <>, Ingemar Johansson S <>, tsvwg IETF list <>
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <>
Subject: Re: [tsvwg] Another tunnel/VPN scenario (was RE: 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, 03 Dec 2020 17:44:40 -0000

[ Charset UTF-8 unsupported, converting... ]
> Just on that last point, perhaps we should be clearer by what 
> "experiment" means.
> On 03/12/2020 15:52, Jonathan Morton wrote:
> > Frankly, the sooner the WG understands and accepts that basic fact, the sooner we can move to a viable solution - one which does not redefine CE from the semantics established by RFC-3168 and RFC-8511, and hence does not place burdens on networks which have no interest in the L4S experiment.
> I think we need to be clear that I understand the proposal is to an 
> Internet-wide experimental deployment.
> If succesful, I'd expect we'll discover things in the deployment that 
> will make us consider new things, before this is approved as a PS. The 
> WG might later decide to obsolete RFC-3168, or L4S, or neither, or both. 
> That will be to decide in future. In persepective, about 15 years passed 
> before the previous EXP use of ECT(1) was made made historic, enabling this.

That 15 years is one reason the opponents of L4S are so very concerned
about the lack of solid, operable positive test data on the current
"state of art" L4S, aka the lack of a viable transport protocol that
COULD be depoloyed on the internet using the L4S middle box signalling.

If a mistake is made here in going forward with this experiment as
it exists today the failure recovery is a very long tail.

> Gorry
> -- 
> G. Fairhurst, School of Engineering
Rod Grimes