Re: [pmtud] comments and discusses on draft-ietf-pmtud-method-10

Michael Tuexen <> Thu, 26 October 2006 18:49 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1GdAHk-0006WY-W4; Thu, 26 Oct 2006 14:49:00 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1GdAHg-0006Tw-3R; Thu, 26 Oct 2006 14:48:56 -0400
Received: from ([] by with esmtp (Exim 4.43) id 1GdAGU-00084f-E3; Thu, 26 Oct 2006 14:47:46 -0400
Received: from [] ( []) by (Postfix) with ESMTP id 0EBCE245CA; Thu, 26 Oct 2006 20:47:35 +0200 (CEST) (KNF account authenticated via SMTP-AUTH)
In-Reply-To: <>
References: <>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Michael Tuexen <>
Subject: Re: [pmtud] comments and discusses on draft-ietf-pmtud-method-10
Date: Thu, 26 Oct 2006 20:47:31 +0200
To: Lars Eggert <>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c
Cc:,, IESG Group <>,
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Dear all,

just a comment regarding I-D.ietf-tsvwg-sctp-padding document.
It was last called in the WG and the comments are integrated in the  
version currently available.

Best regards

On Oct 26, 2006, at 6:31 PM, Lars Eggert wrote:

> Hi,
> draft-ietf-pmtud-method-10 has gathered some discusses and comments  
> during IESG evaluation. The most serious one is probably David  
> Kessens'. I encourage the authors to try and resolve these with the  
> discussing ADs.
> Lars
> Jari Arkko:
> Comment:
> [2006-10-25] > Some protocols may require additional packets after  
> a loss to detect
> > it promptly (e.g., TCP loss detection using duplicate
> > acknowledgments).  Such a protocol SHOULD wait until sufficient data
> > and window space is available so that it will be able to transmit
> > enough data after the probe to trigger the loss detection mechanism
> > in the event of a lost probe.
> It would be useful to have some additional suggested
> parameters that guide how long such wait should be.
> Brian Carpenter:
> Discuss:
> [2006-10-25] This is very welcome document and I hope this issue
> can be quickly resolved:
> > 5.2.  Storing PMTU information
> ...
> >    If IPv6 flows are in use, an implementation MAY use the IPv6  
> flow id
> >    [RFC2460][RFC1809] as the local representation of a path.   
> Packets
> >    sent to a particular destination but belonging to different  
> flows may
> >    use different paths, with the choice of path depending on the  
> flow
> >    id.  This approach will result in the use of optimally sized  
> packets
> >    on a per-flow basis, providing finer granularity than MTU values
> >    maintained on a per-destination basis.
> One problem here is that the informative reference to RFC 1809  
> needs to
> be replaced by a normative reference to RFC 3697 (which updates 2460).
> The second problem is that the flow label is not a routing tag.
> The second sentence is therefore very speculative. I believe the third
> sentence is misleading and should say something much more tentative
> such as "Such an approach could theoretically result...".
> Bill Fenner:
> Comment:
> [2006-10-25] Normative reference to draft-ietf-tsvwg-sctp-padding  
> may cause delay.
> Russ Housley:
> Comment:
> [2006-10-24]
>   The Abstract seem a little bit long.  Maybe it can be reworded to
>   include less of the information that is also in the Introduction.
> David Kessens:
> Discuss:
> [2006-10-26]
> In section '7.2.  Selecting initial values'
> It is RECOMMENDED that search_low be initially set to an MTU size
> that is likely to work over a very wide range of environments.  Given
> today's technologies, a value of 512 bytes is probably safe.  For
> IPv6 flows, a value of 1280 bytes is appropriate.  The initial value
> for search_low SHOULD be configurable.
> When 1280 was selected as the minimum MTU for ipv6, it was choosen
> because it was considered that there were no (reasonable) media that
> cannot at least support a MTU of 1280 and that 1280 bytes was therefor
> a 'safe value'. Why is it that this document
> recommends a different value for ipv4 while it really deals with the
> same problem. Basically, why penalize short lived tcp connections
> over normal media for pathological cases ?
> Combined with the following advice in section '7.3.  Selecting  
> probe size':
> However, for
> some protocols, such as TCP, failed probes are more expensive than
> successful ones, since data in a failed probe will need to be
> retransmitted.  For such protocols, a strategy that raises the probe
> size in smaller increments might have lower overhead.
> it might take a long time before you reach the proper MTU size.
> Considering that I would not qualify 'TCP' as 'some' protocol as it
> normally is the majority of all traffic on any network this can have
> major consequences for the number of packets that need to be processed
> by all routers in the network, especially with a large number of  
> short lived connections. In addition to this, the end-user  
> experience might
> suffer as well. Obviously, this all depends on the exact algorithm  
> choosen
> for raising the probe size which is underspecified at best.
> Did anybody do any research in this topic ? Did anybody run any
> simulations based on the actual traffic mix that we see on the  
> Internet?
> Without that (please correct me if I am wrong), I believe we cannot
> recommend this work as a Proposed Standard. Maybe experimental with
> a clear warning that it supposed to be used to research the issue, but
> not for full scale deployment.
> I also received a review by Pekka Savola from the Ops Directorate.
> Please fix the first issue that he brings up or convince me that he is
> wrong ;-). See below for his full review:
> The first one is probably Discuss unless some other AD picks it up
> first, the rest more editorial comments.
> Section 5.4: "  It is worth noting that classical PMTUD does not  
> work at all as
>   PTB messages are never generated in response to packets with
>   multicast destination addresses [RFC1112][RFC2460]."
> ==> while this is correct for v4, it is not true for v6.  RFC1981
> specifically includes text on how to do PMTUDv6 with multicast.
> RFC2460 also includes discussion on how ICMP errors may be generated
> in response to a multicast packet.  See RFC 4443 section 2.4 clause
> e.3.  So, while this error must be corrected, it can easily be done by
> just rewording (or removing) this paragraph and no further changes are
> required.
> Abstract is not very abstract.  A shorter, single paragraph version
> might be better.
> Section 4: "All Internet nodes SHOULD implement PLPMTUD ..", yet the
> doc says that each protocol needs to have its own implementation of
> PLPMTUD.  So it's not quite clear what the above requirement means.
> That at least one of the protocols of the node should implement
> Section 13.1, I-D.ietf-tsvwg-sctp-padding is a normative reference,
> but the state is still "AD watching".  Hence this document will have
> to wait in the RFC-ed queue.
> Dan Romascanu:
> Comment:
> [2006-10-25] I like the way this document (especially section 7)  
> deals with operational and initial deployment considerations,  
> analyzing carefully the impact of the usage of the discovery method  
> in the Internet.
> Mark Townsley:
> Comment:
> [2006-10-25]
> The abstract is very long. I recommend sticking with just the first  
> paragraph, and moving the rest to an introduction section  
> (eliminating redundant information).
> -- 
> Lars Eggert                                     NEC Network  
> Laboratories
> _______________________________________________
> pmtud mailing list

pmtud mailing list