On 10 mrt 2008, at 23:17, Dave Thaler wrote: > 1) Section 3.2 should motivate better why Path MTU Discovery doesn't > already solve this problem. Certainly one issue is that the router > has to communicate a value larger than the link MTU in the IP-over- > foo document, no question about that. But once that is done, why do > you need the ND probing mechanism as opposed to PMTU discovery?
RFC 1191 PMTUD requires that hosts receive ICMP too big messages. In order to be able to generate those, a router (I guess a switch could also do it) must first successfully receive a packet, then determine that it is too big to be forwarded and then it can return the too big message. On a link with variable MTUs the second step is not possible without additional communication of per-destination MTUs, and even then "invisible" layer 2 devices can get in the way. These layer 2 devices can't do step 1 because of hardware limitations. However, it is possible to do RFC 4821 style PMTUD rather than the more explicit mechanisms, but this has a number of limitations, mostly that it works at the transport layer so that you need to implement it in each transport protocol and that it's not possible to determine whether a given host or a given session supports RFC 4821 or not. > As pointed out in 3.2 already, the main scenario for this draft is > on-link communication (since anything else will be limited by the > minimum path MTU which will generally be a standard number), in > which case ICMP blocking isn't really an issue, and PMTU Discovery > can already discover a per-neighbor MTU that's lower than the link > MTU. So more motivating text seems warranted. I'll see if I can come up with something. You are right that this is a subnet-local thing (hence the title), although there are of course effects that transcend the local subnet. > 2) Section 4.1: Why put the number "600 Mbps" in the doc? Seems > like this number would become obsolete over time, and it would just > just as easy to put the threshold in the option. 600 is just below 622 Mbps OC-12 which makes for a good cutoff and it also works out nicely for a future extension that I have in mind. (A common jumboframe size is 9000 bytes = 6 x 1500 so at 600 Mbps with 9k delay is the same as 100/1500.) I don't have a problem with putting the value in the protocol but there doesn't seem to be much advantage to that. Except maybe at some point in the future where we want new hosts to use 32 MB packets while slow 802.11xyz hosts operating at just 8 Gbps should use 512 kB packets... With 1 Gbps or higher delay over the internet is almost exclusively determined by the length of the path (speed of light) so at gigabit speeds packets of sizes that we currently consider reasonable (64k or smaller) aren't a problem. At 10 Mbps, using 9k packets can hurt delay/ jitter sensitive applications, this is what administrators should be able to avoid. > 3) Section 4.5 says: >> However, the node MUST be prepared to receive packets up to the >> SAFEMTU size. > Per RFC 2460, it is not a requirement that a node be able to receive > packets larger than 1500 bytes. This MUST seems to change that > without explicitly saying so. The draft also specifies what a node should do if it can't conform to the MUST, which is a bit odd. I'll try to find a way to have this make more sense. > I also have a couple minor editorial comments which I will just send > to the author. Got those. Thanks for the comments! Iljitsch _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
