last-hop routers, raising the MTU

smb@research.att.com Sat, 09 December 1989 19:12 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA10533; Sat, 9 Dec 89 11:12:46 PST
Received: by decwrl.dec.com; id AA08364; Sat, 9 Dec 89 11:12:43 -0800
From: smb@research.att.com
Message-Id: <8912091710.AA20665@hector.homer.nj.att.com>
Received: by hector.homer.nj.att.com id AA20665; Sat, 9 Dec 89 12:10:34 EST
To: mtudwg
Subject: last-hop routers, raising the MTU
Date: Sat, 09 Dec 1989 12:10:33 -0500
>From: hector!smb

When Jeff proposed that the last-hop router could send back the requisite
message, I objected.  I no longer consider my objections to be valid.

First, I said that the router might not know the host's MTU.  It has to,
or it wouldn't know how to fragment packets addressed to that host.
In fact, theoretically it needs to know that hosts can handle, say,
1500 bytes on an Ethernet-to-Ethernet relay, or it would be obligated
to use 576 bytes.

Second, I said that what appeared to be the last hop might not be the
last hop, if ARP-fakery is going on.  Again, this doesn't matter much.
Both confused router and the smarter one doing the fakery can send back
MTU messages; the originating host should simply believe the lowest MTU
reported to it.


On another matter, in response to my suggestion that perhaps it wasn't
necessary to ever raise an MTU, several people suggested slowing down
the rate drastically, say to every 30 minutes.  I don't buy that.  The
programming complexity necessary to reprobe is the same whether the
interval is every 30 seconds or every 30 minutes.  Then we have to
worry about what rate is right for what net, or for the metric as
reported by the router, how to make it adaptive (slow-start MTU discovery?),
etc.  I'd be much happier with a passive mechanism that only reduced
the MTU, and never mind trying to increase it later during the connection.


		--Steve Bellovin