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

Joseph Touch <touch@strayalpha.com> Mon, 16 March 2020 15:41 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 C255D3A0A53 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 08:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=0.001, 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 nhgKEGFES2MD for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 08:41:57 -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 989C53A07D0 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 08:41:57 -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:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=DrU/E0C7Ag5HdcQoMs6h0lG+Y8JvEyK0/bXNk3kZhXA=; b=WTbTMnnv0tBZiS27m45q/pckd lWo1P18z0pScZVRAS38u6eV6ZHmcngzcSEHPGakbM3fyK6OMG0fmUOo0P50QDB5slkfi/y6UBjfjI pKhZdg3kzexhik+EM5pKLp7au0Wb9iPpWWm/mG16wMAZTw5OT6WBXEO77vdjKg1EbG9Ar5CLQ1s/p Tey4noMfjrZq58NVvbyLRpA9g/h0qKxruVlXXRk/0i/n+aNMR7s/xNsyqFaLQD6gi27QjpToq+oiS frMPpk3mLWaf2XcVwvQ6gLqJ8C0IochuaWcKf8fC6BCzW9Tq54NCYjlotM9zzV3UUL8zy50lbztI/ ErW1nwHow==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53203 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 1jDrsF-002cAS-8Y; Mon, 16 Mar 2020 11:41:55 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D4EB5E7B-3DDA-4D0B-996F-B1CEECF83FA5"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <25F001C3-083B-442E-8CB7-88EEF32E1974@gmx.de>
Date: Mon, 16 Mar 2020 08:41:50 -0700
Cc: Bob Briscoe <ietf@bobbriscoe.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-Id: <B5996C0B-C5B6-4F33-B5F5-CA1522BC8DFC@strayalpha.com>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com> <3ee6e427-9dc9-e885-21a9-df9e35d99006@bobbriscoe.net> <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com> <5d8f11f3-9def-14b1-4923-4eb02caf51eb@bobbriscoe.net> <50B14177-EB29-4273-839C-D22CCC47511E@gmail.com> <4f66ba3e-9eed-03cd-7f45-a1d7d10ec697@bobbriscoe.net> <FF777393-47B2-4B53-AD41-5883B2D67CC5@gmail.com> <264398ad-59eb-7cfd-0276-35ae0f0120a5@bobbriscoe.net> <44EB050C-C35C-47A0-BC78-3EEDB683B507@gmail.com> <c802dddc-8a55-47ea-9976-06771d39c952@bobbriscoe.net> <B3A657D0-EA9D-45EC-8003-21D158F83E06@gmx.de> <ea8fd9d7-82bc-7da0-a08d-31a2d46abe36@bobbriscoe.net> <D0036DCD-424F-46B0-819B-D9E60828CB50@gmx.de> <8acc44d5-d003-2a92-460e-81f31a26cc9b@bobbriscoe.net> <25F001C3-083B-442E-8CB7-88EEF32E1974@gmx.de>
To: Sebastian Moeller <moeller0@gmx.de>
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/Okwi3pG-r5Jd5fIZmeeN5N5apA8>
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 15:41:59 -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.

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

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

Joe