On 4 mrt 2008, at 16:29, Templin, Fred L wrote: >> 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.
> I don't think we are seeing this quite the same way. AFAICT, > one of the principle advantages of RFC4821 is that it can be > implemented on one side of the connection only and will work > even if no PTBs are received. You are comparing the situation where there are black holes because the ICMP too bigs don't make it to the situation where you have RFC 4821. The latter situation is obviously better than the former, even if one end supports RFC 4821 and the other doesn't, that way you at least solve the black holes in one direction. What I'm comparing is the situation where MTU information is distributed through RA and ND options and probing, which SHOULD be 100% foolproof on a given subnet (although you can still have the black holes on longer paths) with the situation where one end of the communication implements RFC 4821 with no RA or ND options or at least no probing, and the other end doesn't implement RFC 4821 but does implement RA/ND options and probing. When looking at it this way, the former is superior to the latter. Only when BOTH sides implement RFC 4821 things get better, but even then only for a subset of all transports. > If the administrator knows that there are 10Mbps links > interspersed in the otherwise 1Gbps topology, why not > just get rid of the 10Mbps links? That would be the optimal solution, yes. But until you can do that, you can set MAXMTU low so you don't get trouble because of the large packets on the slow link. >>>> 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? > Not sure what you mean, but the cases do exist. Yes, the situation exists, but does it make sense to implement extra logic to make it work better than it does today? The current model for handling MTU sizes is discovery, not explicit signaling. You could imagine a situation where routing protocols carry MTU information for all destinations, but we don't do that. I want to be careful with adding more complexity that only has benefits in a small number of installations because the feedback I've been getting so far has consistently been in the direction of "it has to be simpler". Iljitsch _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
