[pmtud] [Fwd: AD review of draft-ietf-pmtud-method-09.txt]
Matthew J Zekauskas <matt@internet2.edu> Thu, 07 September 2006 15:16 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLcO-0001c0-Li; Thu, 07 Sep 2006 11:16:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GLLcM-0001ab-Sj for pmtud@ietf.org; Thu, 07 Sep 2006 11:16:38 -0400
Received: from basie.internet2.edu ([207.75.164.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GLLaW-0002d9-Re for pmtud@ietf.org; Thu, 07 Sep 2006 11:14:45 -0400
Received: from localhost (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 8AB0947E35 for <pmtud@ietf.org>; Thu, 7 Sep 2006 11:14:44 -0400 (EDT)
Received: from basie.internet2.edu ([127.0.0.1]) by localhost (basie.internet2.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14641-08 for <pmtud@ietf.org>; Thu, 7 Sep 2006 11:14:44 -0400 (EDT)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 349EB47D77 for <pmtud@ietf.org>; Thu, 7 Sep 2006 11:14:43 -0400 (EDT)
Message-ID: <45003760.5040303@internet2.edu>
Date: Thu, 07 Sep 2006 11:14:40 -0400
From: Matthew J Zekauskas <matt@internet2.edu>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: pmtud@ietf.org
X-Enigmail-Version: 0.94.0.0
Content-Type: multipart/mixed; boundary="------------030004000702070801030200"
X-Virus-Scanned: by mail.internet2.edu virus scanner
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 7f3077fcbbd2d4a1504dfa044ebcf773
Subject: [pmtud] [Fwd: AD review of draft-ietf-pmtud-method-09.txt]
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Errors-To: pmtud-bounces@ietf.org
FYI. I believe the authors are going to revise the document to address these points. --Matt
--- Begin Message ---Very nice document. The long list of comments below is pretty much only about using more RFC2119 terms where I thought it appropriate. (I may have missed some and gotten others wrong, so a careful read with a focus on RFC2119 may be a good idea.) INTRODUCTION, paragraph 13: > This document describes a robust method for Path MTU Discovery > (PMTUD) that relies on TCP or some other Packetization Layer to probe > an Internet path with progressively larger packets. This method is > described as an extension to RFC 1191 and RFC 1981, which specify > ICMP based Path MTU Discovery for IP versions 4 and 6, respectively. Does it "update" or "obsolete" any of these two? If yes, add the respective lines in the ID header. The IESG has also recently started to request that drafts explicitly say what they update or obsolete in both the abstract and introduction. Section 1.1.1., paragraph 2: > Changed MAY to SHOULD supress congestion control response on failed Nit: s/supress/suppress/ Section 5.2., paragraph 1: > protocol. The observed PMTU (eff_pmtu in Section 7.1) can optionally > be shared between different flows with a common path representation. s/can optionally/MAY/ Section 5.2., paragraph 4: > The IP layer is the best place to store cached PMTU values and other > shared state such as MTU values reported by ICMP PTB messages. "is the best place" -> rephrase as SHOULD Section 5.2., paragraph 5: > Ideally, this shared state should be associated with a specific path s/should/SHOULD/ Section 5.2., paragraph 7: > An implementation could use the destination address as the local s/could/MAY/ Section 5.2., paragraph 8: > destination cache. Storing the minimum value is suggested since NATs > and other forms of middle boxes may exhibit differing PMTUs > simultaneously at a single IP address. "is suggested" -> rephrase as SHOULD Section 5.2., paragraph 9: > Note that network or subnet numbers are not suitable to use as > representations of a path, because there is not a general mechanism > to determine the network mask at the remote host. "are not suitable" -> rephrase as MUST NOT Section 5.2., paragraph 10: > If IPv6 flows are in use, an implementation could use the IPv6 flow s/could/MAY/ Section 5.2., paragraph 11: > For source routed packets (i.e., packets containing an IPv6 routing > header, or IPv4 LSRR or SSRR options), the source route may further s/may/MAY/ Section 5.2., paragraph 12: > qualify the local representation of a path. An implementation could > use source route information in the local representation of a path. s/could/MAY/ Section 5.3., paragraph 1: > This document does not take a stance on the placement of IPsec > [RFC2401], which logically sits between IP and the Packetization > Layer. The PLPMTUD implementation can treat IPsec either as part of s/can/MAY/ > IP or as part of the Packetization Layer, as long as the accounting > is consistent within the implementation. If IPsec is treated as part > of the IP layer, then each security association to a remote node may > need to be treated as a separate path. If IPsec is treated as part > of the Packetization Layer, the IPsec header size must be included in > the Packetization Layer's header size calculations. s/must/MUST/ Section 5.4., paragraph 3: > Minimally, an implementation can maintain a single MTU value to be s/can/MAY/ Section 5.4., paragraph 4: > used for all multicast packets originated from the node. This MTU > should be sufficiently small that it is expected to be less than the s/should/SHOULD/ Section 5.4., paragraph 5: > path MTU of all paths comprising the multicast tree. If a path MTU > of less than the configured multicast MTU is learned via unicast > means, the multicast MTU may be reduced to this value. This approach s/may/MAY/ Section 5.4., paragraph 6: > If the application using multicast gets complete delivery reports > (unlikely because this requirement has poor scaling properties), > PLPMTUD could be implemented in multicast protocols so that the s/could/MAY/ Section 6.1., paragraph 3: > PLPMTUD can also be implemented in protocols that rely on timeouts as > their primary mechanism for loss recovery; however, timeouts should > be used only when there are no other alternatives. s/should/SHOULD/ Section 7.1., paragraph 10: > eff_pmtu may be greater than search_low. The initial value of > search_low should be conservatively low, but performance may be s/should/SHOULD/ Section 7.2., paragraph 1: > The initial value for search_high should be the largest possible s/should/SHOULD/ Section 7.2., paragraph 2: > packet that might be supported by the flow. This may be limited by s/may/MAY/ Section 7.2., paragraph 4: > It is recommended that search_low be initially set to an MTU size s/recommended/RECOMMENDED/ Section 7.3., paragraph 4: > Each Packetization Layer must determine when probing has converged, s/must/MUST/ Section 7.3., paragraph 5: > that is, when the probe size range is small enough that further > probing is no longer worth its cost. When probing has converged, a > timer should be set. When the timer expires, search_high should be s/should/SHOULD/g Section 7.4., paragraph 1: > Before sending a probe, the flow must at least meet the following > conditions: s/must/MUST/ Section 7.4., paragraph 3: > For protocols that probe with in-band data, when not enough data is > available to probe, the protocol may wish to delay sending non- probes s/may/MAY/ Section 7.4., paragraph 4: > in order to accumulate enough data to send a probe. A delayed > sending algorithm such as Nagle [RFC0896] should be used to s/should/SHOULD/ Section 7.4., paragraph 5: > 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 s/should/SHOULD/ Section 7.5., paragraph 1: > Once a probe size in the appropriate range has been selected, and the > above preconditions have been met, the Packetization Layer may s/may/MAY/ Section 7.6., paragraph 1: > When a probe has completed, the result should be processed as s/should/SHOULD/ Section 7.6.1., paragraph 2: > delivered. To be robust in such a case, the Packetization Layer > should conduct MTU verification as described in Section 7.8. s/should/SHOULD/ Section 7.6.2., paragraph 3: > If an ICMP PTB message is received matching the probe packet, then > search_high and eff_pmtu may be set from the MTU value indicated in s/may/MAY/ Section 7.6.3., paragraph 1: > longer timeout. A timeout value of five times the non-timeout > failure case (Section 7.6.2) is recommended. s/recommended/RECOMMENDED/ Section 7.6.4., paragraph 1: > MTU limitation. In this case, it is appropriate to update no state, "it is appropriate" -> MAY/SHOULD? Section 7.7., paragraph 1: > Under all conditions, a full stop timeout (also known as a > "persistent timeout" in other documents) should be taken as an s/should/SHOULD/ Section 7.7., paragraph 3: > If there is a full stop timeout and there was not an ICMP message > indicating a reason (PTB, Net unreachable, etc., or the ICMP message > was ignored for some reason), the suggested first recovery action is s/suggested/RECOMMENDED/ Section 7.8., paragraph 3: > single path. However, to increase robustness, an implementation > should implement some form of MTU verification, such that if s/should/SHOULD/ Section 7.8., paragraph 5: > A recommended strategy would be to save the value of eff_pmtu before s/recommended/RECOMMENDED/ Section 7.8., paragraph 6: > intervals), then the new MTU is considered incorrect. The saved > value of eff_pmtu can be restored, and search_high reduced in the "can be" -> SHOULD be? Section 8., paragraph 1: > Packetization Layers are encouraged to avoid sending messages that "are encouraged to avoid" -> SHOULD NOT? Section 8., paragraph 3: > smaller than the packet. In some case, packets could be fragmented > more than once if there were cascaded links with progressively > smaller MTUs. This approach is not recommended. s/not recommended/NOT RECOMMENDED/ Section 8., paragraph 4: > It is recommended that IPv4 implementations use a strategy that s/recommended/RECOMMENDED/ Section 8., paragraph 5: > mimics IPv6 functionality. When an application sends datagrams that > are larger than the effective Path MTU they should be fragmented to s/should/SHOULD/ Section 8., paragraph 6: > link MTU of the first network hop directly attached to the host. The > DF bit should be set on the fragments, so they will not be fragmented s/should/SHOULD/ Section 9., paragraph 1: > described in Section 10.4 or to implement diagnostic tools for > debugging problems with PMTUD. There must be a mechanism that s/must/MUST/ Section 9., paragraph 3: > these modes is suitable for implementing PLPMTUD in an application or > diagnosing problems with path MTU discovery. A third mode is needed s/needed/REQUIRED/ Section 10.2., paragraph 2: > The recommended method for generating probes is to add a chunk s/recommended/RECOMMENDED/ Section 10.3., paragraph 3: > To support IP fragmentation as a Packetization Layer under an > unmodified application, we propose to rely on the path MTU sharing "we propose to rely" -> rephrase with SHOULD Section 10.3., paragraph 4: > only be able to take advantage of the minimum of the two. Other > methods that probe only the forward path are preffered if available. Nit: s/preffered/preferred/ Section 10.3., paragraph 7: > less) prior to probing a path to measure the MTU. For this reason we > suggest that IP fragmentation use an initial eff_pmtu which is "we suggest" -> rephrase with SHOULD Section 10.4., paragraph 2: > echoed. This combination (akin to the SCTP HB plus PAD) is preferred s/preferred/RECOMMENDED/ Section 11., paragraph 2: > Since this algorithm is designed for robust operation without any Nit: "this algorithm" -> PLPMTUD? -- Lars Eggert NEC Network Laboratories--- End Message ---
_______________________________________________ pmtud mailing list pmtud@ietf.org https://www1.ietf.org/mailman/listinfo/pmtud
- [pmtud] [Fwd: AD review of draft-ietf-pmtud-metho… Matthew J Zekauskas