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

Joseph Touch <> Mon, 16 March 2020 21:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60C803A11C2 for <>; Mon, 16 Mar 2020 14:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Status: No, score=-1.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c3ULVeEUVpah for <>; Mon, 16 Mar 2020 14:38:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E32663A11FE for <>; Mon, 16 Mar 2020 14:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FMG75l+gaDpcygmCR6W8q5vnL2xl/Wa8a4vOga5zlek=; b=Cp/u+J4SglDWCXiZDwF5ZLQW9 INQpRaWzH425ZwX1aj1r4TsmG9Ud2geL+jcGQZhbIf4RHSaoqZrrC40OjmlBi9s3lE/BexIwYZhv+ nU2F+3w7v/GgFWLcJbvuKEr4GTfpLMXnX1hxeKzo9noMNFnvvAKT6GdOETor3vJy06hBSnUn2my0r 4XNqGhIZlRdMEvV2ItsLr3/blJwfvArsaVgkSHLjYZqnfFloAPCUYMqEkgI5CXVcuM6qoCuni9cOi ZHAD3gv/PTDI5VEmUfcaVf3QHmtqWdAZeW63mXWn3eQ533dX/nlrboftErJTjJeBvEDTjsDUnoE0L /kelYCLiQ==;
Received: from ([]:54470 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1jDxRS-000ioE-R9; Mon, 16 Mar 2020 17:38:39 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Mon, 16 Mar 2020 14:38:34 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Rodney W. Grimes" <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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: Mon, 16 Mar 2020 21:38:52 -0000

> On Mar 16, 2020, at 2:30 PM, Rodney W. Grimes <> 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. 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...
>> 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.
> This is partially true, so long as the configuration of the networks that cause traffic to enter the inner tunnels use a proper MTU for that inner layer.  

That’s not always possible. If the net runs over minimal IPv6 links, there’s no way to ensure a traffic can support 1280B packets over 1280B tunnels.

> This is a common problem with IPSec over PPPoE.  As long as you configure the sources(sender) to use a inner tunnel MTU no issue occurs.

You don’t always know where or when these are and doing this isn’t possible in some cases (see above; you’d end up claiming you support IPv6 but not supporting the min required MTU).

>  This is infact a very common situation with VPS's, often leading to end nodes with MTU's in the 14xx range.  In theory one could nest IPSec until the inner most MTU became the IPvX minimal MTU and so long as the inner most tunnel interface device had the properly adjusted MTU property no fragmentation would occur at any layer in the recursive tunnels.
>> 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).
> Again not always true.  One can properly configure things such that no fragmentation on the inner tunnel occurs by applying MTU's at the ends (usually the encap/decap points).

See above for a counterexample.

>> Bob?s doc has the (IMO) correct approach - tunnels are a pair of devices that both do work.
> This would be ideal, but even in todays internet Tunnels are riddled with MTU issues.

IMO, largely because of mistakes as were quoted before - e.g., ignoring DF and trying to fragment the arriving packet rather than fragment/reassembly at the tunnel edges.

> Further note my assertions above do not apply to arbitrary tunnels between unknown end systems, only to tunnels between known end systems, which I believe is the norm.

I don’t know what this refers to; a tunnel is often between endpoints that don’t do a lot to coordinate in advance other than know they are there.