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
- last-hop routers, raising the MTU smb
- Re: last-hop routers, raising the MTU Noel Chiappa
- Re: last-hop routers, raising the MTU Philippe Prindeville
- Re: last-hop routers, raising the MTU Noel Chiappa
- Re: last-hop routers, raising the MTU Jeffrey Mogul