Here is a completely different approach to PMTUD to the one I developed in October. It has the same name (IPTM - ITR Probes Tunnel MTU) and is at the same place:
http://www.firstpr.com.au/ip/ivip/pmtud-frag/ The new scheme should work find for all PMTU limits from below 1500 to 9000 or above. It only requires Sending Hosts to implement ordinary RFC 1191 PMTUD, rather than RFC 4821 Packetization Layer PMTUD. For each ETR which the ITR needs to send "long" packets to (say, longer than 1200 bytes) the ITR creates three variables. IMTU Interface MTU for the Interface via which the ITR sends packets to this ETR. UPME Upper Path MTU Estimate Initialised to IMTU, and adjusted downwards if PTBs (Packet Too Big messages) or failure to get long packets to the ETR indicates there are PMTU limits in the tunnel to this ETR. LPME Lower Path MTU Estimate Initialise to ~1200. Adjust upwards to the value of the longest packet which has been successfully sent to the ETR. There is no need for "Synthetic Probe" packets - which waste bandwidth. All probing is done with a special form of encapsulation of traffic packets, and then (in general) only if the length after encapsulation is between LPME and UPME. Every such probe discovers something definite about the Real PMTU to the ETR, and adjusts UPME downwards (if the packet is not delivered) or LPME upwards (if the packet is delivered). Previously, the idea of using traffic packets for probing PMTU gave me a headache and I avoided it. The new system always uses traffic packets to probe the PMTU. When the packet is too long to be delivered to the ETR, the ITR sends a PTB (Packet Too Big) so the Sending Host's application tries sending the data in smaller packets. No application data should be lost in this probing process. The natural sequence of events should be for the SH to reduce its packet size, with the ITR reducing its UPME variable, until one packet is delivered to ETR. Once this happens, the ITR writes this length (of the encapsulated packet) to LPME. Subsequent traffic packets up to the length of (LPME - ENCAPS) will be sent by ordinary encapsulation. Packets whose length, once encapsulated, lie in the Zone of Uncertainty between LPME and UPME will be sent as probes. Each one will result in one or the other variable being adjusted, with a consequent reduction in the Zone of Uncertainty. I describe the new version of IPTM in terms of Ivip ITRs and ETRs, but also discuss its applicability to the other map-encap schemes: LISP, APT and TRRP. Perhaps this new approach could be used with Fred Templin's SEAL, which has just been significantly revised to version 06: http://tools.ietf.org/html/draft-templin-seal-06 (I will read this soon.) - 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
