Hi Fred, Here is a diagrammatic explanation of how IPTM would works, and a question about how Sprite would work. I haven't been able to understand your ID clearly enough to answer this myself.
http://tools.ietf.org/html/draft-templin-inetmtu-06 http://www.firstpr.com.au/ip/ivip/pmtud-frag/ IPTM only sends a PTB message to the SH after it has reliably ascertained the PMTU to the ETR - and then only when the SH sends it a packet which is of a length which would exceed that PMTU, once it was encapsulated. Until then (with the first such "long" packet, and with any others which arrive while the ITR is probing) "long" outer packets are fragmented, whether or not the inner packet has its DF flag set, to be reassembled at the ETR before decapsulation. A "long" inner packet is one which, once encapsulated, would exceed the ITR's current best estimate of the PMTU. This would initially be a default such as 1280 bytes. If this default value is above the minimum for the protocol, eg. 576 for IPv4, then this value of PMTU to the "core" of the net must be available to every ITR and ETR and would be part of the specification of the ITR-ETR scheme. (Did you mean "1280" instead of "1500" in: "For IPv6, the minimum EMTU_R is 1500 bytes ..." http://psg.com/lists/rrg/2007/msg00623.html ?) The default value would be replaced by a higher value once the probe process was complete. The pattern would be something like this, assuming the SH's initial idea of PMTU to the Destination Host was 1500. I will assume an ENCAPS overhead of 20 bytes (as with IPv4 Ivip, though other ITR-ETR schemes have higher overheads) and that all ITRs and ETRs are located so they have an MTU of at least 1280 from the DFZ. Inner ITR action on SH's idea DH gets packet outer packet of PMTU length following encapsul- to DH ation of inner packet 1500 200 Send outer packet - 1500 The packet the length is less than 1280. 1500 Fragment packet and 1500 The packet commence probing (Less efficient and more error- prone tunnel with 2 packets instead of 1, but this is only for a few seconds, I hope.) 1500 Fragment packet and 1500 The packet continue probing ... etc. Probing complete: PMTU to ETR decided to be 1460. 1400 Send outer packet - 1500 The packet the length is <= 1460. (This length would not necessarily be sent - it is just to show that the ITR will now send longer packets without frag- mentation than before.) 1500 Drop the packet and send the SH a PTB message with value 1440. 1440 Nothing, but the ITR is usually close to the SH, and it doesn't take long for... 1440 Send the outer packet - 1440 The packet the length is <= 1460 (Now the tunnel is handling optimal length packets.) This pattern would continue unless the ITR, with periodic probing, decides that the PMTU is less than 1460 (it might do this quickly if it got a PTB message from a router in a new, more MTU-challenged, path to the ETR), and if the SH sends a packet which would be too big for the new lower value of PMTU. Then the ITR would send another another PTB message to the SH, with a lower value than 1440. Alternatively, occasional probing by the ITR might discover a higher value of PMTU to this ETR, and the SH could discover this increase by trying its luck with a larger packet - and either having it accepted, or rejected with a PTB containing the new higher value, minus 20. Sprite, as I understand it for IPv4 ... (Fred, the "Section 5.5.x" numbers in Figure 2 should be "5.6.x" except for 5.5.6, which should be 5.6.5. Other references in the ID to "5.5.4" etc. may also need correction.) ... actually, I don't understand it clearly enough to describe it. I think Sprite will fragment outer packets, as does IPTM, irrespective of the DF flag of the inner packet. The criteria for which IPv4 outer packets are fragmentable is complex (5.6.4). I am not sure how Sprite handles "large" outer packets while it is probing. Does it fragment them as IPTM does? Or does it do the following, which is the same as what it does for a "long" packet once the PMTU has been reliably ascertained: (5.6.5) "... admits the packet but also sends a PTB message ..." It seems strange to me to send the packet (unfragmented, I assume) while also sending back a PTB message to the sending host. Wouldn't this cause needless traffic and/or confusing signals to the SH if the outer packet does in fact arrive at the ETR and therefore the inner packet is delivered to the destination host? Here I will assume IPv4 only, with 1280 bytes for the default PMTU for every ETR the ITR has not yet probed. I will also assume an encapsulation overhead of 20, although this would typically be higher for Sprite and non-Ivip ITR-ETR schemes. If the ITR sends a PTB message to the SH when the first packet (or multiple packets) length exceeds the default PMTU value and then, after probing, decides the PMTU is 1480, then I am concerned that the SH would get contradictory values in these PTB messages. At first the SH would be told to send packets no longer than (1280 - 20 = 1260) and later, it would be told to send packets no longer than (1480 - 20 = 1460). But if the SH took notice of the first PTB message, it probably wouldn't send any longer packets which would trigger the second. So, if my understanding of Sprite is correct, the SH would experience something like this: Inner ITR action on SH's idea DH gets packet outer packet of PMTU length following encapsul- to DH ation of inner packet 1500 200 Send outer packet - 1500 The packet the length is less than 1280. 1500 Send packet and Probably nothing commence probing - however, if the Send PTB with value packet was a little 1260 1260 shorter, such as 1440, then it may arrive at the ETR in one piece, despite the SH being told it was too big. SH breaks the message into smaller packets and retries: 1260 Send packet and 1260 The packet continue probing ... etc. Probing complete: PMTU to ETR decided to be 1460. 1260 Send outer packet - 1260 The packet the length is <= 1460. 1260 SH would probably keep The packet - sending packets of but more and length <= 1260. Unless shorter the SH was pushy, it packets than would never discover the the ITR-ETR PMTU it could use was tunnel can in fact 1440. handle. - Robin -- 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
