Re: [v6ops] PMTUD issue discussion

Ray Hunter <v6ops@globis.net> Sat, 30 August 2014 17:50 UTC

Return-Path: <v6ops@globis.net>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66BB1A8ABE for <v6ops@ietfa.amsl.com>; Sat, 30 Aug 2014 10:50:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.67
X-Spam-Level:
X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
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 08tI6kI7-gzK for <v6ops@ietfa.amsl.com>; Sat, 30 Aug 2014 10:50:33 -0700 (PDT)
Received: from globis01.globis.net (mail.globis.net [IPv6:2001:470:1f15:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 83A811A8AA4 for <v6ops@ietf.org>; Sat, 30 Aug 2014 10:50:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id D3A6987151A; Sat, 30 Aug 2014 19:50:31 +0200 (CEST)
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jde4D299JS3T; Sat, 30 Aug 2014 19:50:31 +0200 (CEST)
Received: from Rays-iMac.local (unknown [IPv6:2001:470:1f15:73a:f4ce:58cf:a593:2470]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPSA id 92DB4871519; Sat, 30 Aug 2014 19:50:31 +0200 (CEST)
Message-ID: <54020ECC.4000000@globis.net>
Date: Sat, 30 Aug 2014 19:50:04 +0200
From: Ray Hunter <v6ops@globis.net>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: "Fred Baker (fred)" <fred@cisco.com>
References: <0D370E74-688B-4EB3-A691-309A03AF20BA@cisco.com> <53FBA174.2040302@isi.edu> <53FBA6E1.90905@bogus.com> <CAPi140PMeM9omtm11+NHa2ywUfof_tE7HknKExtoEb32mm7L_w@mail.gmail.com> <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com>
In-Reply-To: <71D0D5E8-80E9-430B-8ED4-16C1F99082CC@cisco.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/v6ops/LpHKE91QpPtFiW447jmFsO316nE
Cc: IPv6 Ops WG <v6ops@ietf.org>
Subject: Re: [v6ops] PMTUD issue discussion
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Aug 2014 17:50:35 -0000

Fred Baker (fred) wrote:
> On Aug 26, 2014, at 2:50 AM, Andrew 👽 Yourtchenko<ayourtch@gmail.com>  wrote:
>
>> However, the value of 1 causes a large value of MSS to be used,
>> resulting in about 1.5 second hiccup. So, yeah it "works" but for
>> barely acceptable values of "works"
>>
>> Setting the value to 2 causes the initial MSS to be 512, which
>> "mitigates" the problem and avoided the hiccups on a 100kb file I was
>> testing with - at the expense of almost 3x more packets of course.
>>
>> I think it would be useful to see the discussion of this measure and
>> its applicability/tradeoffs in the draft.
>
> It seems like it might have value to also test the interaction with various initial window settings, and look at its inclusion in other relevant OS’s including FreeBSD, Windows, and MacOSX. My reading of 4821 says it’s grand theory, but I’m not precisely sure how I would write the code. As an initial setting, for example, I could imagine sending an initial burst containing a 9K byte packet, a 1500 byte packet, and a 1280 byte packet in that order, and set the MSS to the the size of the first acknowledgment I receive. How does that relate to IW=10 (RFC 6928)?

Whilst reading your discussion, I had a "what if" brainwave.

Paths are learned via routing. What if Path MTU was also learned via 
routing, rather than being probed for by individual end hosts?

Then I checked: EIGRP discovers the set of 6 metrics (bandwidth, load, 
delay, reliability, minimum MTU, hop count)

MTU is never used in the routing decision AFAICS, but couldn't the local 
router be programmed to generate ICMP PTB messages (as a proxy for 
downstream routers) with a link-local source address to each host if a 
path MTU is going to be exceeded, plus a hint of the actual PMTU 
discovered by routing?

Thus avoiding ICMP PTB message black holes?And avoiding the PLMTUD 
discovery process and extensive probing/ ramp up for every session?
And also avoiding trust issues (as hosts presumably trust their local 
on-link default router)?

Obviously for this to work internet wide, BGP would also need to carry 
an AS-PMTU attribute per AS path.

-- 
Regards,
RayH