What's your favorite MTU?

mogul (Jeffrey Mogul) Tue, 10 April 1990 02:17 UTC

Received: by acetes.pa.dec.com (5.54.5/4.7.34) id AA04266; Mon, 9 Apr 90 19:17:38 PDT
From: mogul (Jeffrey Mogul)
Message-Id: <9004100217.AA04266@acetes.pa.dec.com>
Date: 9 Apr 1990 1817-PST (Monday)
To: mtudwg
Subject: What's your favorite MTU?

After spending a week or so at it, I'm nearly done with a trial
implementation of Steve Deering's DF-based scheme.  Recall that
he expects an "upgraded" router to send ICMP Dest. Unreachable/
Fragmentation needed and DF set (or DU/FNDS) messages with the
currently "unused" field set to the maximum MTU it can forward
on the given path.  Meanwhile, if the router sending the DU/FNDS
is NOT upgraded, it sends 0 in this field, so the sending host
(i.e., the host receiving the ICMP) can at least know to crank
down its path MTU estimate.

Once I figured out that 4.xBSD-based routers all slightly mangle
the Length field in the "Internet header of Original Datagram",
I decided to base my estimate on the (conservatively corrected)
value of this field.  Clearly, though, the estimate has to be
lower than the old IP Length, since that length was too long.

My first approach was to simply cut the length by 25% on each
trial; this, however, didn't seem to scale well.  Suppose one
has end-hosts on FDDI (MTU = 4478) networks and there is a SLIP
link (MTU = 296) in between.  296/4478 = .066, and you have to
raise .75 to the 10th power before the result is < .066.  So,
it would take 10 round-trip times before the sender got an
estimated Path MTU low enough that segments would start making
it to the far end.

If I make the decrement more than 25%, then convergence is faster
but it is likely to be even further from optimal when it does
converge.  So I was a little disappointed.

A little research in the RFC archives, however, suggests that
there are actually very few reasonable values for Path MTUs.
I count about 9, although I could be missing some.  I went
through all the RFCs listed in RFC1130 as describing IP encapsulations,
made a chart of the MTUs specified, and arranged them in declining
order.  Then I grouped similar values together, and picked a set
of plateaus corresponding to the least element in each group.
In most cases, the choice of groups is quite clear; I'm a little
concerned about the plateaus I picked at smaller MTU sizes, but
none of my values is more than 17% from optimal for its group.

The new algorithm is to step down through the plateaus until
you hit one which is lower than your previous attempted IP Length.
In the FDDI-SLIP-FDDI scenario, this converges in 5 RTTs, not 10.
FDDI-Ethernet-FDDI converges in two steps, to within 3% of optimal.

The table at the end of this message shows my results (the figures
in parentheses show how far from optimal the worst-case member of
each group lies).

I would appreciate it if people could correct any mistakes in this
table, and tell me about data links (such as Amateur Packet Radio)
that I've left out.  Also, if I've included any data links that
are completely obsolete, please let me know!


PMTU-plateau	MTU	Protocol   Comments			Specification
		65535	IP	   Official Maximum MTU		RFC 791
		65535	IP-HC      Hyperchannnel		RFC 1044
		 8166	IP-IEEE    IEEE 802.4			RFC 1042
		 4478	IP-FDDI    FDDI				RFC 1103
		 2048?	IP-WB      Wideband Network		RFC 907
		 2002	IP-IEEE    IEEE 802.5			RFC 1042
2002 (2%)
		 1536	IP-EE      Exp. Ethernet Nets		RFC 895
		 1500	IP-E       Ethernet Networks		RFC 894
		 1492	IP-IEEE    IEEE 802.3			RFC 1042
1492 (3%)
		 1006	IP-SLIP    Serial Lines			RFC 1055
		 1006	IP-ARPA    ARPANET			BBN 1822
		  576	IP-X25     X.25 Networks		RFC 877
		  544	Portal	   DEC IP Portal		--------
		  508	IP-IEEE    IEEE 802/Source-Rt Bridge	RFC 1042
		  508	IP-ARC     ARCNET/extended		RFC 1051
508 (13%)
		  296	IP-SLIP    Serial Lines (Van Jacobson)	RFC 1055
		  253	IP-ARC     ARCNET			RFC 1051
252 (17%)

68			IP	   Official minimum MTU		RFC 791

	    Don't Know	IP-DC      DC Networks			RFC 891