[pmtud] [Fwd: AD review of draft-ietf-pmtud-method-09.txt]

[Matthew J Zekauskas <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pmtud