On 3 mrt 2008, at 18:12, Templin, Fred L wrote: >> Do you mean MRU in the sense of largest packets that can be >> reassembled? In that case I don't see too much of a problem because >> this can be set sufficiently high and isn't dependent on any network >> properties but just on the capabilities of the endpoint.
> I mean that the MRU should be set to the maximum of > 2KB and the connected linkMTU of the ETE. That way, if > the ETE's connected linkMTU is 4KB and the ITE is asked > to forward a 9KB packet, the ITE will drop the packet > and send back a PTB instead of admitting the packet into > the tunnel. The next SEAL draft version will say this. The interesting thing is that you don't need to reassemble the whole packet in order to return the too big: for IPv4, once you have the first fragment and a fragment that is outside of your reassembly buffer, you can return the too big. For IPv6, you'd need to reassemble the first 1280 - IP - ICMP bytes so you can return those bytes in the too big. >> Well, someone suggested that probing was unnecessary if you have RFC >> 4821. In the current version of the draft, it's allowed to substitute >> explicit probing as described in the draft with RFC 4821. But this >> isn't completely bulletproof... > IMHO, endpoints that are sending large packets but not > doing RFC4821 are most likely sending the large packets > infrequently and setting DF=0 (for IPv4). Either that, > or doing host-based fragmentation to a fragment size > that is assured of making it through to the other end > (e.g., 1280 bytes for IPv6). I don't see that. RFC 4821 is a per-transport solution, which means that the maximum packet size should be chosen per-transport, and you still have the issue that if the other side doesn't support it and there are no too bigs, you can have black holes. As such, RFC 4821 isn't completely without risks. But as I write in the draft, if you are bitten by PMTUD black holes because you use a larger than normal MTU, you can always dial back your MTU. >> Right, but how is the situation where two 1000 Mbps clouds are >> connected through a 100 Mbps link different from the situation where >> two 10 Mbps clouds are connected through a 1 Mbps link? This is what >> the MAXMTU is for. > How can the router know there is a slow inner link > in-between fast outer links? Is this strictly an > adminstrative function, where the administrator > must have full knowledge of all links in the network? Yes. All the values in the router advertisement MultiMTU option are set administratively. Only the values in the neighbor discovery MTU option are discovered automatically. I'll make this more clear in the next iteration of the draft. >>> Also routers sending RAs to each other can be used as a means >>> to propagate RFC4191 Route Information Options (RIOs). >> Routers use routing protocols for this. (Although those don't carry >> MTU information.) > This gets down again to what is a router and what is a > host? For example, what would you call a device that > turns on IP forwarding and sends RAs with RFC4191 RIOs, > but does not run a routing protocol (as supported under > systems like Linux)? RFC4191 uses the term "type A/B/C > host", but some might think of it as a router of sorts. > Maybe we need to also talk about "type A/B/C" routers? Is it worth the effort addressing these cases explicitly? Iljitsch _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
