Re: last-hop routers, raising the MTU

jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Tue, 12 December 1989 00:09 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA06186; Mon, 11 Dec 89 16:09:48 PST
Received: by decwrl.dec.com; id AA10322; Mon, 11 Dec 89 16:09:45 -0800
Received: by PTT.LCS.MIT.EDU id AA29266; Mon, 11 Dec 89 19:09:40 EST
Date: Mon, 11 Dec 89 19:09:40 EST
From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa)
Message-Id: <8912120009.AA29266@PTT.LCS.MIT.EDU>
To: philipp@gipsi.gipsi.fr
Subject: Re: last-hop routers, raising the MTU
Cc: jnc@PTT.LCS.MIT.EDU, mtudwg

	Apparently I phrased that suggestion unclearly. Only *one* address
would be in the option; the next hop. At each router, the 'next hop' address
would be checked to see if it was that router. If not, some router in the
middle did not understand (and correctly update) the option.
	I'm not saying this is a great idea; it's just a way of telling (in
that particular scheme) if some box in the middle isn't with it. Remember,
incremental deployment is one thing we have to worry about. One thing I
think we *don't* want MTU discovery to do is cause *every* packet to be
fragmented because some intermediate router has a small MTU but didn't say
so. On the other hand, maybe we do want to punish people who don't do MTU
discovery fairly quickly! :-)

	Noel