IETF Logo Mail Archive

Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 07 February 2016 16:15 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2332E1B3C81 for <ipv6@ietfa.amsl.com>; Sun, 7 Feb 2016 08:15:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, 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 EsXZzVUG4-k4 for <ipv6@ietfa.amsl.com>; Sun, 7 Feb 2016 08:15:19 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B7C1B3C7D for <ipv6@ietf.org>; Sun, 7 Feb 2016 08:15:19 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B49F4200A3; Sun, 7 Feb 2016 11:15:24 -0500 (EST)
Received: from obiwan.sandelman.ca (ip6-localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F18FE63751; Sun, 7 Feb 2016 11:15:17 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Fernando Gont <fernando@gont.com.ar>
Subject: Re: Use cases for PMTUD and PLPMTUD (was: RE: 6MAN: Adoption call on draft-hinden-6man-rfc1981bis-01)
In-Reply-To: <56B50394.2010504@gont.com.ar>
References: <2134F8430051B64F815C691A62D983183395EFC6@XCH-BLV-105.nw.nos.boeing.com> <7592.1454699773@obiwan.sandelman.ca> <56B50394.2010504@gont.com.ar>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Sun, 07 Feb 2016 11:15:17 -0500
Message-ID: <14373.1454861717@obiwan.sandelman.ca>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipv6/2BQI5bj2gNLeJlrRsN83RWy1RWI>
Cc: Bob Hinden <bob.hinden@gmail.com>, 6man WG <ipv6@ietf.org>, "Fred Baker (fred)" <fred@cisco.com>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 07 Feb 2016 16:15:21 -0000

Fernando Gont <fernando@gont.com.ar> wrote:
    >> Templin, Fred L <Fred.L.Templin@boeing.com> wrote: > On the other
    >> hand, paths that lead to Internet destinations cannot be > counted on
    >> to deliver the necessary ICMPs. In that case, RFC4821 > provides a
    >> mitigation.
    >>
    >> > But, if we do not believe that there are paths for which traditional
    >> > PMTUD can still be used safely, then we should be working to
    >> deprecate > RFC1981 instead of making it a standard.
    >>
    >> I think that the mitigation is far more reliable than 1981.  So, I'd
    >> rather deprecate RFC1981.
    >>
    >> {I noticed that 4821 is not on by default in most Linux
    >> distros/kernels, and I actually want to know if there is some reason
    >> for it}

    > Yes: convergence time.

Yes, I've noticed that it takes a few re-transmissions on the first
connection to a site in the case where the MTU is limited and the ICMPs are
lost, but when the MTU is unblocked, there is no delay.

An implementation that wanted to avoid even the re-transmissions in the
blocked case could limit themselves to 1280 sized packets and send some 1500
byte probes have gotten through.

If 4821 is turned off, then the connection is mysteriously blocked, and
always fail.

So, your answer does not make sense to me.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.23.0 | Report a Bug | By Email