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 1989 19:09:40 -0500
From: jnc@PTT.LCS.MIT.EDU
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
- 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