On 29 feb 2008, at 17:52, Templin, Fred L wrote: > I'm not looking for the RA to tell an MTU size that will > work across the tunnel once and for always. I want the RA > coming from the tunnel far end to tell the tunnel near end > the MRU the TFE is able to receive w/o respect to the tunnel > path MTU. That way, the TNE can tell whether it even makes > sense to admit a large packet into the tunnel since there > is no point in doing so if the TFE's MRU is too small.
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. >>> 1) Section 1, text beginning: "However, [RFC4821] must >>> be implemented in every transport protocol...", I'm not >>> sure I understand/agree with the point. My understanding >>> of RFC4821 was that incremental deployment was supported. >> Well, if you have RFC 4821 in your TCP implementation that doesn't >> buy >> you anything for NFS or DNS with EDNS0 over UDP. > Oh - I thought when you said "every transport protocol" > you were talkng about every transport protocol on all > nodes everywhere. It is clear now that you were talking > about every transport protocol *of the same node*. I'm > not sure on that point though, because I thought that > at one point RFC4821 had something to say about MTU > sharing between transports of the same node. Need to > check to see if it is still there... That might be helpful, but it's not a solution because you can't be sure that if you have RFC 4821 in TCP but not in UDP, you'll be running TCP with large packets before you run UDP with large packets. [...] > This isn't a failure case for running or not RFC4821, though; > this is a failure case for allowing nodes with diverse MTUs > on links that don't support diverse MTUs. Indeed, this failure > case has nothing to do with RFC4821. 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... I'll have to think about this some more, maybe it would help to specify that since routers can't do RFC 4821 they must stick to safe packet sizes in the absense of explicit probing. >> The idea behind SLOWMTU is twofold: it could be that the slow hosts >> are behind switches that don't support the larger MTU, and even if >> the slow hosts COULD send large packets, that may be undesirable >> because it increases RTTs and jitter. > I am considering the case of fast links at the edges and > slow links in the middle. Something like GigE at the edges > and 100Mbps Ethernet in the middle, i.e., the "dumbell > configuration" yet again! If the nodes on fast links think > they can send large packets based on their attached link > bandwidths, it could be a problem. 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. >>> 3) Section 4.2, perhaps this text is part of what you were >>> meaning about being careful about node, host, route, etc. >>> Particularly interesting is the part beginning: "Devices >>> not acting as IPv6 routers ... MAY send out a router >>> advertisement ...". I think this is worth considering, >>> and also worth considering is whether two routers connected >>> by a virtual link that spans an interdomain routing region >>> (default-free, perhaps) can mutually send RAs with multi-MTU >>> options to one another (with Router Lifetime=0, of course). >> Why would they send out router advertisements? The information about >> the supported MTUs is available in neighbor solicitations/ >> advertisements, which routers DO send to each other. > I thought you were saying the NS/NA functions were optional? Yes. But ND is the right place for this functionality. It doesn't make sense to replicate it in another place, either people think it's not worth the effort, or they should implement it properly. It's not like implementing the ND MTU option is extremely complex. I can see how someone would want to forego probing, but just advertising the local maximum isn't hard. > 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.) >>> The Ras might also contain RFC4191 RIOs, but no RFC4861 PIOs >>> and such. >> Hey, a new neighbor discovery RFC... Managed to miss that. > No; not at all. Standard ND combined with RFC4191. The RFC is new, though. :-) Iljitsch _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
