Re: MTUs on different paths

Steve Deering <deering@pescadero.stanford.edu> Mon, 11 December 1989 11:17 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA27046; Mon, 11 Dec 89 03:17:18 PST
Received: by decwrl.dec.com; id AA29085; Mon, 11 Dec 89 03:17:14 -0800
Received: by Pescadero.Stanford.EDU (5.59/25-eef) id AA07189; Mon, 11 Dec 89 03:16:56 PDT
Date: 11 Dec 1989 2:53-PST
From: Steve Deering <deering@pescadero.stanford.edu>
Subject: Re: MTUs on different paths
To: art@sage.acc.com
Cc: mtudwg
Message-Id: <89/12/11 0253.319@pescadero.stanford.edu>
In-Reply-To: art's message of 10 Dec 89 210000 PST

>	I hadn't seen anyone point out an obvious point, so I thought that
>	I'd add it to the discussion.
>
>	Not only can the MTUs in both directions differ (because of asymetric
>	paths), but the MTUs between a pair of hosts can potentially depend
>	on TOS, precedence, and/or policy if any of these ever gets
>	implemented.

You are right that it hasn't come up in the discussions, but it is
mentioned in both of the written proposals: in the second paragraph
on page 6 of RFC-1063, and in the last paragraph on page 6 of my
draft RFC.

There is, however, a problem with the RFC-1063 approach of allowing
the Reply MTU to be piggybacked on any returning datagram -- the
association between the MTU and its corresponding TOS or other
route-influencing options may be lost.  This leads me to suggest
that there are only three reasonable ways of returning MTU information
to a host:

	(1) in an ICMP message, with the header of the MTU-seeking
	    datagram included.

	(2) in an IP or higher-layer option attached to a higher-layer
	    acknowledgement of an MTU-seeking datagram.

	(3) in an IP option that contains *all* of the relevent
	    information (TOS, security, etc.), attached to any datagram
	    returning to the source of an MTU-seeking datagram.

Steve