Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

John Leslie <> Tue, 17 March 2020 06:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 699A73A190F for <>; Mon, 16 Mar 2020 23:19:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id swFXMEH1imu5 for <>; Mon, 16 Mar 2020 23:19:40 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id DF7C63A18F6 for <>; Mon, 16 Mar 2020 23:19:39 -0700 (PDT)
Received: by (Postfix, from userid 104) id 0BEE3629C3; Tue, 17 Mar 2020 02:10:26 -0400 (EDT)
Date: Tue, 17 Mar 2020 02:10:25 -0400
From: John Leslie <>
To: Joseph Touch <>
Cc: Sebastian Moeller <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
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: Tue, 17 Mar 2020 06:19:43 -0000

On Mon, Mar 16, 2020 at 08:41:50AM -0700, Joseph Touch wrote:
>> On Mar 16, 2020, at 2:12 AM, Sebastian Moeller <> wrote:
>>> [BB] I should add that PLPMTUD and clamping the max packet size
>>> complement each other. 
>>> PLPMTUD without clamping would kill latency.
>>> Clamping avoids triggering fragmentation, but smaller than max
>>> packet sizes are inefficient. 
>>> Adding PLPMTUD eventually bumps up the MTU for each path to its max,
>>> removing the inefficiency.
>> [SM] Well, realistically the ONLY viable solution is to design all
>> tunnels to allow the de facto real-world internet MTU of 1500 and
>> just make sure the tunnel itself uses jumbo-frame capable links
>> to make sure fragmentation is not required...

   Never say "never!" (isn't that what "ONLY" means?)

   Yes, jumbo-frame capable links really _are_ essential...

>> But honestly, in our current context I still wonder whether an operator
>> failing to implement a non-fragmenting tunnel will ever deploy an
>> ECN-enabled AQM...

   Again, never say "never".

   Implementing non-fragmenting tunnels really isn't that hard! It's
just that so few people act as if they beleieve it necessary. :^(

> That won???t work either. Any tunnel that has an MTU of any type
> (e.g., even the max MTU for IP of 64KB) and can be used recursively
> either directly (X over X) or indirectly (X over Y over ??? over X)
> MUST support fragmentation somewhere.

   Yes, even 64KB MTU can be exhausted!

   We need better tunneling algorithms...

> Intermediate recursion tunnels can implement fragmentation at any
> of the protocols. Directly recursive tunnels MUST implement
> fragmentation (because nobody else can in way that helps).

   I'm not sure this is the best way to say it.

   The word "fragmentation" carries an awful lot of baggage. :^(

   I will own up to having done some _evil_ things in a past life,
such as running slow links with MTU less than 1500 to simplify life.

   We need descriptions of problems that come from running tunnels
without a tunnel-path MTU greater than the incoming MTU.

   (Of course there are things you can do as an alternative; but
they tend to be harder.)

   Where we get in trouble is pretending the problem can be ignored.
Alas, _many_ pointy-haired-bosses believe they can define the problem
out of existence. :^( :^(

> Bob???s doc has the (IMO) correct approach - tunnels are a pair of
> devices that both do work.
> Joe

John Leslie <>