Hi,
Lars
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:
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...".
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 ?
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.
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.
==> 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.
-- Lars Eggert NEC Network Laboratories
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pmtud mailing list pmtud at ietf.org https://www1.ietf.org/mailman/listinfo/pmtud