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

"Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net> Tue, 17 March 2020 03:09 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 7ECA13A163F for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 20:09:42 -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 do-i7lsMaz_F for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 20:09:41 -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 7BE153A081E for <tsvwg@ietf.org>; Mon, 16 Mar 2020 20:09:41 -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 02H39c0a095719; Mon, 16 Mar 2020 20:09:38 -0700 (PDT) (envelope-from ietf@gndrsh.dnsmgr.net)
Received: (from ietf@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 02H39cGF095718; Mon, 16 Mar 2020 20:09:38 -0700 (PDT) (envelope-from ietf)
From: "Rodney W. Grimes" <ietf@gndrsh.dnsmgr.net>
Message-Id: <202003170309.02H39cGF095718@gndrsh.dnsmgr.net>
In-Reply-To: <A78EAD49-37D3-4A65-A21D-A004AADA31A4@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
Date: Mon, 16 Mar 2020 20:09:38 -0700 (PDT)
CC: Jonathan Morton <chromatix99@gmail.com>, "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/2oCdtzhsXpjMXCpZ0-0-ZI4TG20>
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 03:09:43 -0000

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

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.

> Joe
-- 
Rod Grimes                                                 rgrimes@freebsd.org