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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Mon, 16 March 2020 21:30 UTC

Return-Path: <ietf@gndrsh.dnsmgr.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069EE3A11A9 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 14:30:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.623
X-Spam-Level:
X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.274, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMrZUkhdghAp for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 14:30:16 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA3A3A11A8 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 14:30:15 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 02GLUB9j094639; Mon, 16 Mar 2020 14:30:11 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 02GLUBRv094638; Mon, 16 Mar 2020 14:30:11 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202003162130.02GLUBRv094638@gndrsh.dnsmgr.net>
In-Reply-To: <B5996C0B-C5B6-4F33-B5F5-CA1522BC8DFC@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
Date: Mon, 16 Mar 2020 14:30:11 -0700 (PDT)
CC: Sebastian Moeller <moeller0@gmx.de>, "tsvwg@ietf.org" <tsvwg@ietf.org>
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/GPgsL4aBswOwViHpCPwECeG14jw>
Subject: Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Mar 2020 21:30:24 -0000

> > On Mar 16, 2020, at 2:12 AM, Sebastian Moeller <moeller0@gmx.de> 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.  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.  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).

> 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.

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.

> Joe
-- 
Rod Grimes                                                 rgrimes@freebsd.org