[RRG] Path MTU Discovery: a new approach

[Robin Whittle <rw@firstpr.com.au>]

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 rrg-request@psg.com 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