Hi Fred, There are no-doubt mistakes in my attempt to understand your goals and broader assumptions with SEAL - so please correct them.
I will write a separate message on how IPTM could be improved to handle IPv4 DF=0 packets. The note below * discusses the possibility of IPTM ITRs sending DF=1 traffic packets encapsulated as DF=0. - Robin The SEAL Internet Draft is: http://tools.ietf.org/html/draft-templin-seal I was reading version 08 from yesterday, but now it is version 10. The Diff1 comparisons show only low-level differences in techniques between the two - not differences in what I think are assumptions and goals. A terse description of my new IPTM (ITR Probes Tunnel MTU) proposal with follow-up discussions is here: http://psg.com/lists/rrg/2008/msg01191.html RW http://psg.com/lists/rrg/2008/msg01197.html BH http://psg.com/lists/rrg/2008/msg01199.html RW The full description is here: http://www.firstpr.com.au/ip/ivip/pmtud-frag/ Differing scopes ---------------- SEAL is a general purpose protocol for application to many tunneling situations, one of which is ITR --> ETR tunnels in map-encap schemes, such as LISP, APT, Ivip or TRRP. (It isn't compatible with Ivip's use of outer source address = Sending Host's (SH's) address, but I am still keen to learn from it and assist its development.) SEAL is intended to work with many other tunneling systems, including long-lasting 2-way tunnels. Map-encap ITR --> ETR tunnels are transient and one-way. SEAL is intended to be a single protocol, used by others. IPTM (and its subsidiary RPD2 PMTUD probing protocol) is intended primarily for Ivip, but I want to develop it in a way that it could be adapted to other map-encap schemes, or be used with suitable adaptations for other purposes, perhaps including SEAL. IPTM is not a standalone protocol. It is an approach which should work well for Ivip, and from which some or a lot will (ideally) be adaptable to other scenarios. Other than its potentially broader applications, IPTM is intended solely for the challenging task of an ITR (most particularly in an Ivip system) getting packets to an ETR, including when the ITR initially has no information at all about where this ETR is, or what the Real PMTU to this ETR is. IPTM should also adapt to changes in the Real PMTU. As part of this, the ITR is assumed to receive packets from the Sending Host (SH). Perhaps that SH is itself a tunneling device, with the real communication occurring from some other host, and the destination address of the traffic packet is really the end-point of some tunnel, not the destination host of the underlying communication. Either way, the ITR is assumed to be able to get PTBs to the SH, and if the SH is doing any kind of tunneling, it is assumed to be doing its own PMTU management of whatever it sends to the DH. Differing goals --------------- Ignoring IPv4 DF=0 packets for the moment (I am writing a separate message on this) the goals of IPTM are: 1 - Send all traffic packets with the minimal necessary encapsulation overhead into the tunnel, to the ETR, so that the vast majority of them never encounter any PMTU limits. * As currently described, IPTM sends IPv4-in-IPv4 packets to the ETR with DF=1. (I didn't specify this - just assumed it.) Maybe it would be desirable to send them with DF=0, to enable them to be fragmented by any router in the tunnel which has an MTU which is lower than the ITR expects - that is lower than LPME. That would increase robustness, since as currently defined if the packets were DF=1, the ITR would get no PTB. The router's PTB would be sent to the SH, which would not recognise it. With fragmentation, the packets have a good chance of arriving, whereas without this, they would be dropped and it would be up to the application (such as with RFC 4812 Packetization Layer PMTUD) to figure out something was wrong - or to wait for the ITR's occasional explorative RPD2 probing to find that the Real PMTU was lower than LPME. I will think about this more. I suspect it would be more trouble than it is worth - but maybe not. 2 - Send PTBs to the RFC 1191 compliant SH (as all are assumed to be) in a way which reliably reduces the size of the SH's outgoing packets for this ETR, such that very soon, they are of a size which once encapsulated, fits within the Real PMTU of the tunnel. Ideally, this size fits exactly within the Real PMTU, so the system works with maximum efficiency. This involves not sending any PTBs with an unnecessarily low value of MTU, since RFC 1191 hosts will not try to send packets longer than that value for 10 minutes. 3 - Discovery of the Real PMTU is done by using traffic packets encapsulated in a different manner - RPD2 - from the normal encapsulation (for Ivip, 20 byte IP-in-IP with outer source address = that of the SH). RPD2 produces a packet of the same length as usual, but also involves 2 or 3 smaller packets as well (these numbers are not fixed in stone) which accompany the main packet. 4 - Apart from occasional explorative use of RPD2 for packet lengths shorter than LPME, or longer than UPME (and apart from Synthetic Probes with RPD2, as discussed below for PMTUD with DF=0 packets), the RPD2 probing technique is only used for traffic packets whose length falls within the Zone of Uncertainty between LPME and UPME. (See a separate message for how I plan to use Synthetic Probe packets with RPD2 in order to probe the PMTU to an ETR when there are no longer DF=1 packets being sent, only longer DF=0 packets.) 5 - This main use (not the occasional explorative use) of RPD2 always (apart from in extreme cases of random packet loss) results in the ITR learning something reliable about the Real PMTU, and so adjusting LPME up or UPME down. 6 - For IPv6 and IPv4 DF=1 packets, the overall outcome is that the ITR will quickly discover good upper and lower estimates for the Real PMTU to the ETR, and cause the SH to send packets which once encapsulated by the normal techniques, will be sent along the tunnel without any PMTU limits and without any fragmentation or segmentation (special in-tunnel techniques for breaking the traffic packet into smaller pieces at the ITR and reassembling it at the ETR). 7 - Therefore, IPTM is intended to quickly adjust each SH's RFC 1191 notion of PMTU to each of its Destination Hosts for which the ITR encapsulated packets longer than ~1200 bytes, to the optimal value for efficient operation. (AFAIK, SHs which send DF=0 packets are not able to receive any instructions from the network regarding packet size.) 8 - IPTM does not embody any assumptions about the prevalence of ~1500 byte MTUs, or of 9000 byte MTUs. So it should be able to adapt seamlessly to all future MTU sizes without any trade-offs or configuration changes. There is, however, an assumption that all ITRs and ETRs can send packets of a certain size - say 1200 bytes - without any PMTU problems. I am very happy about this, because I had thought there needed to be some ugly assumptions and config changes as the world transitions from primarily 1500 byte MTU systems to primarily 9000 byte MTU systems. Reading up to 4.2.4 (08 to 10 changes are all from 4.2.6 onwards) I get the strong impression that SEAL's goals are rather different. The goals seems to be something like this: 1 - SEAL does not assume or require anything like IPTM's assumption of at least a ~1200 byte PMTU clear path from any ITR to any ETR. (ITE to any ETE for SEAL, since the proposal is for many settings beyond map-encap.) 2 - SEAL seems to assume that the ITE could be getting packets which have already been wrapped in one or more layers of encapsulation - that is they are tunnel packets, and the ITE sees the outer header, without knowing how many layers of encapsulation there are. IPTM copes fine with this too. 3 - SEAL assumes it cannot send PTBs to the original SH of the original packet which is encapsulated to form the whole traffic packet it handles. This is true of IPTM too. IPTM assumes the ITR can send PTBs to what the ITR regards as the SH, which in this case is the last encapsulator - and expect that device, whatever it is, it to reduce its packet lengths accordingly. If this assumption is not true, then my view is that that SH is expecting too much of the Network (including the ITR, which it has no direct knowledge of or relationship with) in putting out packets which are in fact unsuitable for efficient carriage to the DH, whilst ignoring PTBs sent to it. I think it would be worse than useless for the Network to go to special trouble to carry the packets of such SHs. Maybe this is one of SEAL's goals. I think those SHs need to change their PTB-ignoring ways! (I think the Network shouldn't go to any special trouble to increase the reliability of long DF=0 packets either. Does SEAL go to any such extra trouble?) 4 - SEAL seems to assume that the initial SH is putting out packets of ~1500 bytes and that by various layers of encapsulation since then, the total packet size of the traffic packet the ITE needs to handle has grown to some larger value, such as between 1520 and somewhat below 2048 bytes. 5 - SEAL seems to assume that the ITE has no prospect of altering the size of these 1500 byte packets which have been bloated by encapsulation to be potentially too large to fit through the smallest MTU of the routers in the tunnel to the ETE. 6 - SEAL allows for there being multiple other layers of encapsulation in the tunnel to the ETE. 7 - Therefore, SEAL attempts to handle packets up to ~2048 bytes in size, and to get them by hook or by crook, to the ETE, despite there being MTU limits in the tunnel which are well below 1500 bytes. Differing mechanisms -------------------- The mechanisms within IPTM (including RPD2) are very different from those within SEAL. I don't clearly understand SEAL's, in part because I am still trying to understand SEAL's goals and in part because I find it hard to construct a systematic view of SEAL's algorithm for handling packets of different sizes. Discussion ---------- Initially I assumed that SEAL (and before that SPRITE-MTU) had goals pretty close enough to my own at the time. My October 2008 approach to IPTM was a much messier conception than now, focussing on trying to handle ~1500 byte packets via tunnels through ISP and end-user networks and the DFZ in which we may have a PMTU to the ETR of: 1500 - map-encap ENCAPS - other unseen ENCAPS overheads or we may now, and increasingly later, have: 9000 - map-encap ENCAPS - other unseen ENCAPS overheads while we have now, and increasingly later, hosts which want to send ~9000 byte packets. Now I see the goals of these two proposals as very different. I don't think SEAL in its current state would be anywhere near as suitable for a map-encap system as IPTM. I wonder whether SEAL could be adapted or something like it could be created to be a general-purpose protocol, useful outside map-encap, and which embodies the relatively open-ended approach of IPTM - which I am really happy doesn't involve any hard assumptions about prevalent MTUs, except for assuming ~1200 clear path to the tunnel end-point. -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
