MTU stuff

Steve Deering <> Mon, 11 December 1989 10:52 UTC

Received: from by (5.54.5/4.7.34) id AA26902; Mon, 11 Dec 89 02:52:06 PST
Received: by; id AA27026; Mon, 11 Dec 89 02:52:02 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA06695; Mon, 11 Dec 89 02:50:49 PDT
Date: 11 Dec 1989 1:41-PST
From: Steve Deering <>
Subject: MTU stuff
To: mtudwg
Message-Id: <89/12/11>

Some more random comments.

I'm puzzled.  Some of you reject the report-fragmentation approach
because it causes fragmentation to occur every once in a while.
Instead, you suggest the use of an IP option to discover the
MTU in advance.  For performance reasons, you realize you don't
want to send the option very often.  But that means that a
downward change in MTU can cause *many* more of the dreaded
fragmentations to occur, until you get around to asking for the
MTU again.

Keith's report-next-N-fragmentations scheme addresses this problem,
but requires messy state maintenance and probably degrades performance
(matching the state -- dest/TOS/etc. -- and counting up to N).

Assuming an IP-layer MTU cache, my scheme causes fragmentation to occur
for one RTT every 10 or 15 minutes, only on those paths whose MTU is
smaller than you want to send [i.e., less than MIN(MSS,first-hop-MTU)].
Doesn't sound like such a big deal to me.  This strategy of "banging
your head against a brick wall just to check if the wall is still there"
(in Keith's words) is exactly analogous to Van's algorithm for
determining the optimum window size, in which an occasional packet
loss is tolerated.

On the question of whether or not a gateway can tell if it is the last
hop for a particular datagram, the semantics of strict source routing
make it mandatory that a gateway be able to tell if a destination
is directly reachable.  If proxy ARP or subnetting implementations are
deceiving some gateways, then they are violating the security assumptions
behind strict source routing.

Furthermore, while it may be true that a gateway may not know the
MTU of a neighboring host, the gateway is only required to fragment
a datagram to the "natural" MTU of the intervening subnet.  That means,
if a host advertises an MSS of any value less than or equal to the natural
MTU of its connected subnet, then the host's MTU must be at least as
big as that MSS.  That is:

	host-MTU must be >= MIN (advertised-MSS, subnet-MTU)

	e.g., an Ethernet host must not advertise an MSS of 1500
	      if its MTU is only 576.

(Not exactly right, since MTUs include space for the IP header and MSSs
don't, but you get the idea.  I also am overlookng the issue of subnets
with no "natural" MTU, such as HyperChannel, or with more than one
"natural" MTU, such as bridged abominations.)