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

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
Michael

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]
>   COMMENT
>
>   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
> +ICMP
>   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
> PLPMTUD?
>
> 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@ietf.org
> https://www1.ietf.org/mailman/listinfo/pmtud

_______________________________________________
pmtud mailing list
pmtud@ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud