Iljitsch, >-----Original Message----- >From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] >Sent: Monday, March 03, 2008 2:28 AM >To: Templin, Fred L >Cc: Internet Area >Subject: Re: [Int-area] Multi-MTU subnet draft > >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.
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. >>>> 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... 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'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. Again, the philosophy adopted by SEAL is "take care of the smalls, and let the bigs take care of themselves". >>> 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. 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? >>>> 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.) 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? >>>> 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. :-) Not so new that it hasn't been implemented under widely deployed OSs, though... Fred [EMAIL PROTECTED] > >Iljitsch > _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
