Re: last-hop routers, raising the MTU

Philippe Prindeville <philipp@gipsi.gipsi.fr> Mon, 11 December 1989 23:51 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA06062; Mon, 11 Dec 89 15:51:49 PST
Received: by decwrl.dec.com; id AA08007; Mon, 11 Dec 89 15:51:42 -0800
Received: from gipsi.gipsi.fr by inria.inria.fr (5.61+/89.0.8) via Fnet-EUnet id AA19894; Mon, 11 Dec 89 23:49:29 +0100 (MET)
Received: by gipsi.gipsi.fr; Mon, 11 Dec 89 16:10:42 -0100 (MET)
Date: Mon, 11 Dec 89 16:10:42 -0100
From: Philippe Prindeville <philipp@gipsi.gipsi.fr>
Message-Id: <8912111510.AA16797@gipsi.gipsi.fr>
Phone: +33 1 30 60 75 25 / +33 1 47 34 42 74
To: jnc@ALLSPICE.LCS.MIT.EDU
Subject: Re: last-hop routers, raising the MTU
Cc: MTU Discovery <mtudwg>

		However, this gives me an idea: the bug with 1063 is that it
	doesn't work if all the intermediate routers (and end host) don't
	understand it.  Maybe we can tell if one of the routers along the way
	didn't grok it?  I thought of a number of algorithms, but this one seems
	best: suppose each hop puts the address of the next hop in the option;
	when the option is seen in incoming processing, you check the address to
	see if it's yours. If not, somebody didn't grok the option, and you set
	the MTU to 576.

"Loose source route record", "Strict Source Route Record", now "Source Route
and MTU Record"...

This sounds really broken.  One wants to find out the MTU of a dynamic
route (yes, I know it doesn't change that often), rather than fix the
route and then discover (almost by hazard) the MTU.  It is putting the
cart before the horse (mixing apples and oranges, and half a dozen other
cliche's).

-Philip