Re: How to use an IP-header bit for Path MTU discovery. (Fred Bohle acc_gnsc) Tue, 20 February 1990 18:58 UTC

Received: from by (5.54.5/4.7.34) id AA22590; Tue, 20 Feb 90 10:58:01 PST
Received: by; id AA27679; Tue, 20 Feb 90 10:57:46 -0800
Received: from SATURN.ACC.COM by (5.61/1.34) id AA01949; Tue, 20 Feb 90 10:58:27 -0800
Received: by (5.51/1.28) id AA20278; Tue, 20 Feb 90 13:55:53 EST
Date: Tue, 20 Feb 90 13:55:53 EST
From: (Fred Bohle acc_gnsc)
Message-Id: <>
Subject: Re: How to use an IP-header bit for Path MTU discovery.
Cc: mtudwg

Chuck writes:
>Message-Id: <9002192335.AA12085@PTT.LCS.MIT.EDU>
>To: "John M. Wobus" <>
>Subject: Re: How to use an IP-header bit for Path MTU discovery. 
>At the Sending Host:
>The IP user (e.g., a TCP connection) turns on the "RF Option" (or
>header flag, if you prefer) on "appropriate" outgoing IP datagrams.
>This option/flag is NOT copied on fragmentation (i.e., it always
>sticks to the first fragment).

Sending an RF option/bit once per RTT should minimize the processing
overhead at the gateways/hosts processing datagrams and still discover
a smaller MTU if fragmentation occurs at multiple gateways.  Probing for 
a larger MTU at a frequency similar to the congestion-window probe
frequency will allow for discovery of a larger MTU if a re-route
takes place.  All this logic takes place at the TCP layer, yet is
still processed at the IP layer to maintain the MTU size in its routing
tables.  That is my suggestion for "appropriate outgoing IP datagrams".

>At the Last Hop Gateway (post fragmentation processing):

Doing this at ALL gateways has the advantage of helping in the
case of partial distribution of this support.  Those gateways
which support RF bit processing will report fragmentation they
observe or perform.  (On the other hand, it may take more than
one round trip to discover the true minimum MTU.)

>If the "RF Option" is set on a locally-destined packet, and if the MF
>flag is set on said packet, then the gateway sends an ICMP Report
>Fragmentation message back to the source.

Or if it will SET the MF flag in the outgoing message (i.e. this
gateway is doing the fragmenting).

>The Total Length field of
>the IP header in the data portion of said ICMP message will reflect
>the least MTU along the path. The "RF Option" of said packet is
>then removed/turned off, the header checksum is recomputed, and
>the packet forwarded on its way.

This only discovers the smaller MTU discovered so far in the route.
That is why I suggest one RF datagram per RTT to discover the next
fragmentation point.

>At the Receiving Host:
>If the "RF Option" is set on a received packet, and if the MF
>flag is set on said packet, then the host sends an ICMP Report
>Fragmentation message back to the source (as above).
>... In cases where both the
>last hop gateway AND the receiving host have the new software,
>the result would be 2 ICMP messages directed back at the source.
If the RF bit is turned off when the ICMP message is sent, only one
ICMP message can be sent.  Therefore the ICMP message will not destabilize
the network load.

>A weakness of this idea is that it does not win at all if neither
>the last hop gateway nor the receiving host has new software.
>... If you aren't stopping fragmentation
>completely (on a given path), there seems little point in (possibly)
>reducing it.

It will stop fragmentation on all but the last hop of the route.
If that hop does not require fragmentation, it wins big.  Isn't
the long-haul network usually the one requiring small datagrams?

This approach makes sense, since the primary responsibility of
reporting fragmentation is the gateway which is fragmenting.  The
use of the RF bit then becomes one of advertising the ability to
do something about fragmentation at the source.  Partial distribution
of the implementation gives incremental gains.

Fred Bohle			EMAIL:
ACC				AT&T : 301-290-8100 
10220 Old Columbia Road
Columbia, MD 21046