Iljitsch, >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >Sent: Wednesday, March 05, 2008 1:16 AM >To: Templin, Fred L >Cc: Internet Area >Subject: Re: [Int-area] Multi-MTU subnet draft > >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. I'm afraid we are still disconnecting; path MTU discovery is a unidirectional function, and needs to be handled seperately over the paths from A->B and B->A - even if A and B are neighbors on the same link. RFC4821 makes things better going from A->B even if only node A implements it. (The same is true for going from B->A.) About the RA/ND options, they may only apply for links that occur in the middle, whereas path MTU concerns end-to-end. >> 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. So, if there *might* be some 10Mbps links in an otherwise 1Gbps topology, set MAXMTU=1500 for all and forget about it? >>>>> 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". This I think is starting to spin off in random directions that have nothing to do with this discussion; to be sure, no one is talking about adding any extra logic. Fred [EMAIL PROTECTED] > >Iljitsch > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
