Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06

Joe Touch <touch@isi.edu> Wed, 26 April 2017 20:34 UTC

Return-Path: <touch@isi.edu>
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 84CFE1294AB; Wed, 26 Apr 2017 13:34:07 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] 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 ulEldP2NKcW2; Wed, 26 Apr 2017 13:34:06 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAE9129464; Wed, 26 Apr 2017 13:34:06 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v3QKXrTa006565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 13:33:53 -0700 (PDT)
Subject: Re: [Gen-art] Genart telechat review of draft-ietf-6man-rfc1981bis-06
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fred Baker <fredbaker.ietf@gmail.com>
Cc: gen-art@ietf.org, 6man WG <ipv6@ietf.org>, IETF-Discussion Discussion <ietf@ietf.org>, draft-ietf-6man-rfc1981bis.all@ietf.org
References: <149305392811.25808.15115824976388262628@ietfa.amsl.com> <497d3868-406a-a38f-56d8-391b0fc16032@isi.edu> <a974da1d-a9e7-8c64-8086-0955f2dffb12@gmail.com> <f6088ab8-3533-96f1-d9eb-f8462b1f4a1b@isi.edu> <99FD5A05-EDBE-4764-941C-C95BD689237B@gmail.com> <a7c8a2d8-6a67-e78c-a3d9-7bf7f0b767a9@gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <c1888839-94fb-437c-a9af-e8309308cc8b@isi.edu>
Date: Wed, 26 Apr 2017 13:33:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1
MIME-Version: 1.0
In-Reply-To: <a7c8a2d8-6a67-e78c-a3d9-7bf7f0b767a9@gmail.com>
Content-Type: multipart/alternative; boundary="------------7459DC2F1AB0CBA15FBD1564"
Content-Language: en-US
X-MailScanner-ID: v3QKXrTa006565
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/S_pPB-iI0nmwj63RFk5QTzzrvvQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 26 Apr 2017 20:34:08 -0000


On 4/26/2017 1:30 PM, Brian E Carpenter wrote:
>>> Individual packets and fragments can be smaller than the MTU, of course.
>>> Nothing forces fragments to push up against any MTU limit at all. But I
>>> would not describe that has a host changing its path MTU; it's just
>>> sending packets.
>> I disagree, both on the definition and the action. You are correct in "how the Path MTU is calculated". But the Path MTU, by definition, is the largest packet that can be sent end to end under current routing conditions. It is not, actually, an IP concept: it's a TCP concept if anything, or a transport layer concept (if UDP ever decides to have one). I can imagine TCP probing the Path MTU by trying packets that are larger than its current estimate to see if the estimate is still accurate (1981 section 4), but I can't imagine any reason that TCP would send packets larger than the "largest packet that can be sent end to end under current routing conditions" in the normal case, as those packets will by definition either be fragmented or not arrive.
> istm that the robustness principle argues for what Fred is saying. Yes, any path that doesn't transmit 1280 byte packets is breaking the law, but (given that the protocol police do such a lousy job) if the objective fact is that the path only transmits 1279 byte packets, what's best for the user?
IMO, the best thing is to loudly flag the path as no longer valid.

Either we have required minimums or not. If not, then we have a LOT of
new work to do.

Joe