How to use an IP-header bit for Path MTU discovery.

"John M. Wobus" <JMWOBUS%SUVM.BITNET@CORNELLC.cit.cornell.edu> Mon, 19 February 1990 20:29 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA16519; Mon, 19 Feb 90 12:29:28 PST
Received: by decwrl.dec.com; id AA13003; Mon, 19 Feb 90 12:29:22 -0800
Message-Id: <9002192029.AA13003@decwrl.dec.com>
Received: from SUVM.ACS.SYR.EDU by CORNELLC.cit.cornell.edu (IBM VM SMTP R1.2.1MX) with BSMTP id 3486; Mon, 19 Feb 90 15:29:28 EST
Received: by SUVM (Mailer R2.03B) id 8513; Mon, 19 Feb 90 15:28:04 LCL
Date: Mon, 19 Feb 90 15:24:34 EST
From: "John M. Wobus" <JMWOBUS%SUVM.BITNET@CORNELLC.cit.cornell.edu>
To: mtudwg
Subject: How to use an IP-header bit for Path MTU discovery.

If an IP header bit is to be dedicated to MTU discovery, then one strategy
for using it is to send it in exactly those cases where the recipient host
ought to try something it normally wouldn't.

For example, if a useful behavior is to normally set the MTU to 576 (I'm
speaking of inter-network traffic here: traffic on a LAN would have its own
rules) but to use some higher number (say 1500) when doing so causes no
fragmentation, then the bit might be defined as follows:

   The bit means that the sending host has received no fragmented
   packets from the recipient.

Each host-route entry would include a flag meaning "the last oversized
packet I received from this recipient was NOT fragmented".  It should be
turned on when the host route is created.  A host would simply copy this
bit into all the IP packets that it sends to the other host and would
start out with its favorite large MTU.

Recipients of this bit use it by simply switching to a smaller MTU (576)
if the bit is clear.  If they are talking to a host without the feature,
they simply always switch down.

The advantage of this plan is that it will work smoothly with any other
hosts which ignore the bit.  Also, the bit is the only new thing that has to
be implemented (no ICMP messages or IP options).

Possible disadvantages: is the MTU correctly sized at a time when it will
do any real good?  Are two "candidate" MTU sizes enough?  (note: this
method can probably be adapted to zoom in on intermediate MTUs--the
protocol allows implementations to try one MTU, then another, though it
fails to tell a host exactly when is a good time to believe the bit after
the first time: that would be left to clever implementation) Is it too
much to ask hosts to look up the host route each time it receives a
packet?  (this method requires the host-route entry be looked up each time
an oversized packet is received, be it fragmented or not).  Is it OK to
save such state in host-route entries?  Will some gateways or hosts choke
on the bit?

John Wobus
Syracuse University