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

Joseph Touch <touch@strayalpha.com> Tue, 17 March 2020 04:03 UTC

Return-Path: <touch@strayalpha.com>
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 042003A170B for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
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 0jpayV82MwLb for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 21:03:34 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272653A1707 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 21:03:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=p8sdhhi1184ONZzf9kJVgFprnGHbe2nmVy8ep80TJio=; b=yWF3wYcW30xMT3LKMjDaSmxqK c/S0i+hXpfnlI3wwyRkwAJ9kfHRl54gro24D72MQ/vdgdErIK/KUSr2wWduoRofoxYUSaenKNTmK3 x6949UwdjyEsznowPptsHa9IGYI2l8Vr3Am5DCG7/eKnxjhc1u3nrynsdmJ93B9xmz/yFi8zhWzuT JnBSylW23fu4aGwQOt1LE3fTQY1pHMnur1KUPLU2M0J/6tSUvE4XGLsXzFF0Y5szBwukZjh3PpAmQ O2TiOhnSzfT5S8miB63+b9Bai+W5bcury5dQ1Y8jLGK10h3MR2U1Pc8UemUdUHQdLvSBQVfoEuMgT mT5zIkKaw==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:54944 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1jE3Rv-002uHB-Rz; Tue, 17 Mar 2020 00:03:32 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <202003170309.02H39cGF095718@gndrsh.dnsmgr.net>
Date: Mon, 16 Mar 2020 21:03:26 -0700
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E350CC13-73CD-40ED-B1F5-C79EA7E41490@strayalpha.com>
References: <202003170309.02H39cGF095718@gndrsh.dnsmgr.net>
To: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/73q3drFRKmvKilTImrAPemQL9rc>
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: Tue, 17 Mar 2020 04:03:36 -0000


> On Mar 16, 2020, at 8:09 PM, Rodney W. Grimes <ietf@gndrsh.dnsmgr.net> wrote:
> 
>> 
>> 
>>> On Mar 16, 2020, at 2:42 PM, Jonathan Morton <chromatix99@gmail.com> wrote:
>>> 
>>>> On 16 Mar, 2020, at 11:38 pm, Joseph Touch <touch@strayalpha.com> wrote:
>>>> 
>>>> 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.
> 
> True, not always possible, but very often practical and done as minimal IPv6 links generally only exist inside of tunneled tunnels :-)  ((Ie, GRE -> IPSec -> PPPoE))
> 
>>> 
>>> I think the 1280B minimum was intended to allow for the possibility of running through tunnels on conventional 1500B physical networks.
>> 
>> Actually, the 1280B is the path min; the receiver min is 1500B exactly to allow for this sort of frag/reassembly (where a tunnel egress *is* such a receiver). The 1500B comes from Ethernet; the 1280B is smaller deliberately.
> 
> receiver min?  I am not familiar with that term.

EMTU_R as defined in RFC 1122. See also draft-ietf-intarea-tunnels

> And as you state 1500B no doubt comes from the Ethernet specification.
> 
> I shall endorse Jonathans position with this:
> 	The 1280 IPv6 minMTU originated from a November 14, 1997 mailing
> 	from Steve Deering to the IPng mailing list, which stated:
> 	"In the ipngwg meeting in Munich, I proposed increasing the IPv6
>        minimum MTU from 576 bytes to something closer to the Ethernet MTU
>        of 1500 bytes, (i.e., 1500 minus room for a couple layers of
>        encapsulating headers, so that min- MTU-size packets that are
>        tunneled across 1500-byte-MTU paths won't be subject to
>        fragmentation/reassembly on ingress/egress from the tunnels, in most
>        cases).
> 
> So infact this is all meant to MINIMIZE fragmentation.

Except that it doesn’t unless you KNOW that the path supports 1500B. But there’s no rule in IPv6 that the EMTU_S min is 1280B *AND* the links MUST support 1500B.

I.e., that’s why the EMTU_S min is 1500B - so you can reassemble when you don’t know otherwise. But even when IPv6 was created there were problems with PMTUD.

Joe