Hi Robin, Thanks for taking another look at SEAL. Please see below for just a few comments in response:
Fred [email protected] > -----Original Message----- > From: Robin Whittle [mailto:[email protected]] > Sent: Tuesday, January 26, 2010 8:57 PM > To: RRG > Cc: Templin, Fred L > Subject: Re: [rrg] RANGER and SEAL critique > > Short version: "Jumbograms" are not the same as "jumboframes". > > Discussion of SEAL's support for packets longer > than 1500 bytes and up to 64k bytes - these are > "jumboframes". > > Questions about how SEAL detects the PMTU being > too short for the currently sent packets - it > appears to be based on detecting fragmented packets > for IPv4, and by using ICMP PTBs for IPv6. If so > why not use ICMP PTBs for IPv4 too? > > When would SEAL segmentation be used? I would > have thought it is never desirable to have > ITRs, ITEs or any intermediate router fragmenting / > segmenting packets into two or more smaller packets > on an ongoing basis. Surely the sending host > should be sent a PTB to cause it to send packets > which, once encapsulated, will fit within the > actual PMTU of the ITR/ITE path to the ETR/ETE. > > > Hi Fred, > > I read the current ID: > > http://tools.ietf.org/html/draft-templin-intarea-seal-08 > > I used the term "jumboframe" to denote IPv4 or IPv6 packets which are > up to about 9kbytes long, as opposed to the conventional length of > ~1500 bytes. > > Your current ID and your previous mailing list message used the term > "jumbogram", which is IPv6 only and refers to packets of 65,575 bytes > or more (up to 4 gigabytes) - and which have a "Jumbo Payload" option > header. The terminology is has become a bit loose here since the GigE community began using the term "jumbo" to refer to their 9KB target. For SEAL, what I am meaning to say is that SEAL-SR can handle all sizes from 1500 Ethernet size (or smaller) on the low end up to all sizes of IPv6 jumbograms on the high end. I'll see if I can disambiguate in the text. > My IPTM approach needs to be written up more clearly. As far as I > know, it is the only thing which attempts anything similar to SEAL - > although it is purely for use within Ivip, and assumes that the outer > source address of ordinarily tunneled packets is that of the sending > host, not the ITR. > > http://www.firstpr.com.au/ip/ivip/pmtud-frag/ > > IPTM doesn't have any particular upper limit for packet length, other > than that imposed by the 16 bit length fields in the IPv4 and IPv6 > headers. Any such packet longer than 1500 bytes is properly > referred to as a "jumboframe". IPTM is not intended to support > "jumbograms". > > I think your SEAL proposal is supposed to work with the same - IPv4 > and IPv6 packets with normal headers and lengths up to 65,575 bytes. > If so, then I think "jumbogram" is not the correct term to describe > SEAL's capabilities. > > Assuming that you do aim to handle both IPv4 and IPv6 packets up to > 65,575 bytes, then here is my understanding of how SEAL-SR does it. > > There is new text on page 15: "The ITE can alternatively ...". > Before this text is guidance on how the ITE can set an MTU value on > the input of the tunnel to 1500 bytes or greater, or significantly > lower, such as to 576 bytes for for IPv4 and 1280 bytes for IPv6. It > is not very clear how such decisions should be made. The new text > provides a third option: > > The ITE can alternatively set an indefinite MTU on the tunnel > virtual interface such that all inner IP packets are admitted into > the interface without regard to size. For ITEs that host > applications, this option must be carefully coordinated with > protocol stack upper layers, since some upper layer protocols > (e.g., TCP) derive their packet sizing parameters from the MTU of > the underlying interface and as such may select too large an > initial size. This is not a problem for upper layers that use > conservative initial estimates, e.g., when mechanisms such as > Packetization Layer Path MTU Discovery [RFC4821] are used. > > I understand this as meaning that the ITE (AKA ITR in other CES > architectures) will accept any size packet initially, but may later > change the limit to a lower value and send PTBs to the sending host > (assuming the SH is sending IPv6 packets or IPv4 packets with DF=1). > > As far as I know, no applications use RFC 4821. Can you cite any > which do? RFC 4821 involves different applications sharing > information via the operating system about their experience with > packet lengths sent to a particular destination host. This sounds > complex to implement and text - and I guess there is little > motivation for early adoptors amongst application writers if few > other apps do it. Applications do not know whether they are running on a stack that uses RFC4821 or just classical PMTUD; the use or non-use of RFC4821 is a stack consideration and not an application consideration. > Also, the "ITE which hosts applications" is confusing, since in > RANGER, the ITE is a router. Maybe you mean apps inside the router > which use TCP. Yes; app's inside the router which use TCP. I guess we can use MSS clamping for apps inside the router if we are concerned about them getting too large of an initial PMTU estimate. > My overall understanding is that if the ITE adopts this indefinite > MTU, and adjusts it downwards if any packets are too big for the PMTU > to the ETR, then you can cope with IPv4 and IPv6 packets up to 65,575 > bytes. If so, then this paragraph of my critique no longer applies: > > RANGER uses its own tunneling and PMTUD management protocol: > SEAL. ... > > However I think the ID should be amended to avoid reference to > "jumbograms". > > As best I understand it, SEAL sends all its encapsulated traffic > packets from the ITE to ETE (ITR to ETR) with: > > IPv4 DF=0 > > IPv6 with a Fragmentation header > > I understand the purpose with IPv4 DF=0 is so if the packets are too > long for the PMTU to the ETE, that they will be fragmented and the > ETE will therefore receive at least some of the fragments, and so > report this to the ITE (4.4.5.1.2). This is how SEAL works to detect > PMTU problems in the tunnel - rather than relying on RFC 1191 ICMP > PTB packets generated by routers between the ITE an ETE, at least for > IPv4. > > In IPTM (for both IPv4 and IPv6) I send a pair of packets, one short > and one long, (perhaps a few copies of the short one, to improve > robustness) for any traffic packet which is longer than the ITR has > previously successfully sent to the ETR. The ETR responds to the > shorter one, and tells the ITR if the long one didn't arrive. (Also, > the ETR will reply to the ITR if only the long one arrives.) These > are DF=1 packets for IPv4 and ordinary (implicitly DF=1) packets for > IPv6. I can see how the ETR can send a response for packets that arrive, but then how long must the ITR wait to receive the response? And, what if the response is lost? I can't see how the ETR can send a response for packets that *don't* arrive. For example, what if the large packet was dropped due to congestion and not due to an MTU limitation? And, for how long must the ETR wait before sending the NACK? IMHO, DF=1 for PMTUD is busted, and these are a few of the reasons why. > I think it is bad to send DF=0 packets into the DFZ and expect the > routers to dutifully fragment them if they are too long - though I > know this should not happen frequently with SEAL, since it is just > part of detecting the PMTU. In-the-network fragmentation is a noise indication, and SEAL moves quickly to tune out the noise. > Do DFZ routers handle IPv6 packets with the Fragmentation Header just > as fast as those without? I don't honestly know, but I sure hope that they do. Anyone from the major router vendor community care to comment on this? > With IPv6, does SEAL detect its encapsulated packets being too long > for the ITE to ETE PMTU by relying on ICMP PTB messages from the > limiting router in the ITE to ETE path? (AFAIK, IPv6 packets are > never fragmented by ordinary routers.) If so, then why not do the > same with IPv4 packets? ICMPv6's are guaranteed to include a sufficient portion of the original packet whereas ICMPv4's are not. Hence, the theory is that the ITE can "match up" the ICMPv6s with actual packets that cause the PTB. Also the ICMPv6's can readily be translated into PTBs to send back to the original source while ICMPv4's may not contain enough data for translation. Other than that, both ICMPv6's and ICMPv4's can be dropped by filtering gateways so both IPv6 and IPv4 are susceptible to black-holing. But, for the non-fragmenting IPv6 network using DF=1 this is the best we can do; for IPv4 we can do better by using DF=0. > Assuming the above-mentioned approaches enable each SEAL ITE to > discover the actual PMTU to a given ETE (and to probe occasionally to > see if the value has increased), and assuming it uses this to send > PTB packets to the SH in order that subsequently emitted packets will > be of the right size, once encapsulated, to not exceed this PMTU, > then what is the purpose of the SEAL segmentation system? > > Actually, it is trickier. The one SH may be sending to multiple > destination hosts (DHs) all of which are for one or more EID > prefixes for which the ITE is currently tunneling to a given ETE. > Then the ITE needs to send the SH a separate PTB for each too-long > packet it sends to each such DH. Also, there may be multiple such > SHs using this ITE whose packets will be tunneled to this ETE. > > If the SH sends a really long IPv4 DF=0 packet, the ITE will use > ordinary IPv4 fragmentation to turn it into multiple shorter fragment > packets, before SEAL processing. (I think, come the Revolution, that > DF=0 packets longer than some value like 1450 bytes or similar should > be *dropped* - applications are expecting too much of the Network to > fragment and carry the fragments of their excessively long packets. > Applications have had since 1991 - RFC 1191 - to change their > free-loading ways.) > > > Under what circumstances would SEAL segmentation be used? SEAL is intended not only for the core routers we usually talk about in RRG, but also for any ITR/ETR routers deployed in any operational scenario. For example, we would never ask core routers to do segmentation and reassembly (hence the recommendation for SEAL-FS in those environments). But, we might want to ask routers in edge networks (e.g., MANET routers, CPE routers in ISP networks, etc.) to do segmentation and reassembly in order to avoid having to constantly tell hosts to reduce their PMTU estimate to a degenerate size (i.e., anything less that 1500). So, in those environments we would recommend SEAL-SR. Thanks - Fred [email protected] > IPTM does not do any such thing, except for the rare dual-packet > protocol which is used for probing PMTUD to the ETR. > > I would have thought it highly undesirable to allow SHs to keep > sending packets which the ITE, ITR or whatever should have to turn > into two or more packets just to get to the ETR. > > - Robin _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
