Re: DISCUSS's on rfc1981bis - MK Comments

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sat, 20 May 2017 15:11 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
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 E0A83129B00 for <ipv6@ietfa.amsl.com>; Sat, 20 May 2017 08:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 q9DIS1Oax__S for <ipv6@ietfa.amsl.com>; Sat, 20 May 2017 08:11:40 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1941275AB for <ipv6@ietfa.amsl.com>; Sat, 20 May 2017 08:11:39 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 79FBC1B016C8; Sat, 20 May 2017 18:06:15 +0100 (BST)
Message-ID: <59205C94.30200@erg.abdn.ac.uk>
Date: Sat, 20 May 2017 16:11:16 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
CC: ipv6@ietfa.amsl.com
Subject: Re: DISCUSS's on rfc1981bis - MK Comments
References: <FF803F19-4253-4422-AFA5-B99A8894BD83@gmail.com> <5911B0EE.6080802@erg.abdn.ac.uk> <EC313F56-0193-4510-9CCB-4AEF85F3E590@kuehlewind.net>
In-Reply-To: <EC313F56-0193-4510-9CCB-4AEF85F3E590@kuehlewind.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/T5bagY9C4Ch0ZVwP4FWP3su2OJg>
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: Sat, 20 May 2017 15:11:43 -0000

On 19/05/2017, 15:51, Mirja Kuehlewind (IETF) wrote:
> Hi Gorry, hi all,
>
> thanks for the work and the update. All comments from Gorry seemed fine to me and I will try to review the changes in the updated doc soon. One more minor comment on this:
>
>> Am 09.05.2017 um 08:07 schrieb Gorry Fairhurst<gorry@erg.abdn.ac.uk>:
>>
>>> I don't understand the following paragraph. Can this be removed?
>>> "Note: A packetization layer must not retransmit in response to
>>> every Packet Too Big message, since a burst of several oversized
>>> segments will give rise to several such messages and hence several
>>> retransmissions of the same data. If the new estimated PMTU is
>>> still wrong, the process repeats, and there is an exponential
>>> growth in the number of superfluous segments sent."
>>>
>> GF: I think the example is important. I'm not sure why that would be removed.
> The problem is I don’t understand this example. Is there an assumption that all mtu probe packets have been ‚generated‘ on the same packet? If so that makes sense but must the spelled out somewhere!
>
> Mirja
>
>
I think the wording is maybe jumbled, but the point is OK. Perhaps 
something like this would be clearer?

"Note: A packetization layer ought to avoid retransmitting the data in a probe packet
using the size reported in the last Packet Too Big message.
This is to avoid an exponential growth in the number of superfluous segments
that would be sent when a path encounters several successive smaller PMTU limits.
(Each new estimated PMTU would result in retransmission of the data in a smaller
packet that may itself fail if it encounters a still smaller PMTU in a device further
along the same path)."

Gorry