Re: draft-van-beijnum-multi-mtu-05.txt

Philip Homburg <pch-ipv6-ietf-2@u-1.phicoh.com> Thu, 07 April 2016 13:46 UTC

Return-Path: <pch-bBB316E3E@u-1.phicoh.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B1012D501 for <ipv6@ietfa.amsl.com>; Thu, 7 Apr 2016 06:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 FaCerxMZV75z for <ipv6@ietfa.amsl.com>; Thu, 7 Apr 2016 06:46:39 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-he.hq.phicoh.net [IPv6:2001:470:d16a:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id A9DD212D1B0 for <ipv6@ietf.org>; Thu, 7 Apr 2016 06:46:38 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #91) id m1aoAGX-0000FOC; Thu, 7 Apr 2016 15:46:33 +0200
Message-Id: <m1aoAGX-0000FOC@stereo.hq.phicoh.net>
To: ipv6@ietf.org
Subject: Re: draft-van-beijnum-multi-mtu-05.txt
From: Philip Homburg <pch-ipv6-ietf-2@u-1.phicoh.com>
Sender: pch-bBB316E3E@u-1.phicoh.com
References: <20160406151831.GZ518778@eidolon> <570569C2.4030601@acm.org> <20160406212048.GB518778@eidolon> <20160406220411.GC518778@eidolon> <E27329D1-400E-4470-8277-64A664508854@employees.org>
In-reply-to: Your message of "Thu, 7 Apr 2016 10:27:07 -0300 ." <E27329D1-400E-4470-8277-64A664508854@employees.org>
Date: Thu, 07 Apr 2016 15:46:31 +0200
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/7p4ygW9SNobQSnDuTCKO7UXHa8w>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Apr 2016 13:46:41 -0000

>In general I'd prefer that we reuse existing mechanisms for path mtu 
>discovery, and not invent new ones purely for the case of two directly 
>connected neighbors.

I think making them the same is likely to be sub-optimal.

The nice thing about the current proposal is that the MTU is verified before
any application traffic is sent.

This not going to fly on the internet as a whole. There is no way that
busy DNS servers are first going to send ping traffic back to the client before
sending the DNS reply.

On the other hand, the model behind existing PMTU discovery is reactive. The
loss of a data packet triggers downward adjustment of the estimated PMTU.

In the context of ethernet jumbograms, such a reactive approach is likely to be
unattractive to operators. 

So I'd say that from a PMTU perspective directly connected neighbors are quite
different from the internet as a whole.