YAMDI (Yet Another Mtu Discovery Idea)

[[e-mail]]

In thinking about the issue, I've developed the following preferences:
1)  The mechanism should allow discovery before fragmentation is required
    if possible.
2)  The mechanism should be at the IP level and information cached at that
    level, but the mechanism can be requested at the transport level.
3)  One end of a connection should be able to take advantage of the
    mechanism, even if the other host doesn't support it.
4)  There should little if any state maintained.
5)  Most of the routers are expected to be updated before most of the
    hosts.
6)  Any extra net traffic should only be a direct consequence of a host 
    probing for the MTU.

Based on these, I propose:

A Report MTU IP option which carries the current path estimate and an
ICMP MTU Change Error message which also carries an MTU estimate.

If there is no cached estimate for the path MTU then the IP option is
initialized with the MTU of the directly attached I/F, otherwise the
current estimate is used.
Any router (or the end host) which detects a smaller MTU will update the
option and send an ICMP report back to the source indicating the current
MTU.  Any router (or the end host) which receives fragment 0 of a fragmented
packet, with the option indicating an MTU larger than the fragment, will
update the option and generate an ICMP report.

This option should be used infrequently.  It should probably be used at
initial connection establishment, if no cached value is available.  Thereafter,
it should be inserted occassionally to probe for MTU reduction.  On an even
less frequent interval, it could be sent with the local I/F MTU to probe
for MTU increases.

An end host which receives the option may cache the value for the receive
path, but should endeavor to learn the  MTU for the transmit path to deal
with asymetric routes.  In the absense of a transmit MTU estimate, a receive
MTU estimate may be reasonable candidate.

Feel free to paint a large bull's eye on this and use for target practice.

+-----------------------------------------------------------------------+
|	Art Berggreen		Advanced Computer Communications	|
|	<[e-mail]>	Santa Barbara Street			|
|	[phone]		Santa Barbara, CA 93101			|
+-----------------------------------------------------------------------+