Please see comments below on the current draft. Best wishes,
Gorry (Matt - could you post to the list if this "bounces", I'm working from my laptop as I travel to the IETF and don't have access to my other "gf" account from here). -------------------- * The title does not contain the abbreviation: PLPMTUD - this would greatly help people searching titles to locate the RFC. * page 11, section 4, para 2. "limited clock stabilities" - the scenario and implications of this is not clear. * page 16, section 6.1, para 3. - Mention is made of SACK blocks, it would be good to also cite RFC4341, DCCP-CCID2: DCP CCID 2 uses an ACK Vector that provides information equivalent to that transmitted in a TCP SACK option. * page 18, section 7.2 (and section 7.7, 8) - I like the use of 512 as an acceptable common minimum MTU in the current IPv4 Internet, but this is by no means a required value. If PLPMTUD sets this as a minimum, what can be done if the discovery fails to find a path that supports this MTU? It would be a shame to have this "black-holed". Allowing PLPMTUD to drive the PMTU of a flow down to the minimum for IPv4 appears to me to expose a much bigger DoS threat. IPv4 ICMP messages which suggest such small MTUs may be a big performance hinderance to hosts and routers. One other option available only in IPv4, would be to enable "IP Router Fragmentation - but clearing the DF bit". Is this good, evil or acceptable? * Section 7.6. - This section does not make use of RFC2119, it seems that some of these cases should use "SHOULD" or "MUST". Was this intentional? * Page 21, section 7.6.1, first para - So what must the node do when the reported result of a probe is successful for a smaller PMTU than that which is currently in use. Is this a case where the probe should be treated as successful, but the probe value should be ignored? * Section 7.8 - This looks good. * Section 10 - RFC4340 describes DCCP's Path MTU discovery mechanisms, in section 14. This seems to be compatible with that described for SCTP and DCCP in the current document. Can text be added to describe intended DCCP behavior with PLPMTUD? (I can work with you on this text, if it helps). "DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP endpoint begins by sending small packets with DF set and then gradually increases the packet size until a packet is lost. This mechanism does not require any ICMP error processing. DCCP-Sync packets are the best choice for upward probing, since DCCP-Sync probes do not risk application data loss. The DCCP implementation inserts arbitrary data into the DCCP-Sync application area, padding the packet to the right length. Since every valid DCCP-Sync generates an immediate DCCP-SyncAck in response, the endpoint will have a pretty good idea of when a probe is lost." * Page 27 - I don't particularly like the idea of probing the return path MTU at the same time as the forward path MTU (i.e. Using an ECHO mechanism). There does not seem to be any need for a sender to know the MTU of the return path... For example, a corner case in the use of ICMP-ECHO-REQUEST to probe for bandwidth is that this actually performs a bi-directional test for the PMTU probe size. Paths exist that have assymmetric properties (e.g. Scenarios described in RFC3449), where the response to the probe mail fail, even though the PMTU in the forward direction was accepted. Section 10.4 also talks about the idea of probing the return path. * Page 27, final para (e.g., 1kBytes or less) - Is this thinking directed to IPv4? - Would this better be 512B for IPv4 and 1280 for IPv6 to be consistent with earlier? * Security Considerations - See above. IMHO, it is worth stressing the performance vulnerability of setting an outrageously small PMTU size in IPv4. --------------------------------------------- NiTs for the authors: * The abstract does not include the definition of the abbreviation: PLPMTUD. * The abstract does not include the abbreviation: PMTUD, which would be helpful. * Is section 1.1 to be removed by the RFC Ed? * page 6, section 2, para 2 /protocols which/protocols that/ * page 8 top para PTB should be defined in the text. * page 11, section 4, para 1. /in order to/to/ * page 20, section 7.4 /Section Section/Section/ * page 20, section 7.2 (what is "it"?) /the loss to detect it/a loss to detect it/ * page 20, section 7.5 /equal the probe/equal to the probe/ * Page 25, section 9 /Diagnostic application are/ Diagnostic applications are/ * Page 25, section 9 /be be/be/ * Page 25, section 9 /a probes/a probe/ * Security Considerations /Such and/Such an/ _______________________________________________ pmtud mailing list [email protected] https://www1.ietf.org/mailman/listinfo/pmtud
