Re: last-hop routers, raising the MTU
jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Mon, 11 December 1989 03:55 UTC
Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA24512; Sun, 10 Dec 89 19:55:52 PST
Received: by decwrl.dec.com; id AA26788; Sun, 10 Dec 89 19:55:47 -0800
Received: by PTT.LCS.MIT.EDU id AA25661; Sun, 10 Dec 89 22:55:41 EST
Date: Sun, 10 Dec 1989 22:55:41 -0500
From: jnc@PTT.LCS.MIT.EDU
Message-Id: <8912110355.AA25661@PTT.LCS.MIT.EDU>
To: smb@research.att.com
Subject: Re: last-hop routers, raising the MTU
Cc: jnc@lcs.mit.edu, mtudwg
Whoa! I don't think your assertion that the last hop router will know the host's MTU is correct. Routers have to be able to receive and send the MTU on any interface, but they aren't required to know what any host is using (and have no way of finding that info out anyway). The rule is that 'a host must not send a larger datagram [than 576] without explicit knowledge or prior arrangement with the destination host'. This puts the onus on the end hosts, and frees the routers from getting involved in the game. It is perfectly possible to send a packet to a host that's bigger than the host is ready to receive.... 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. I don't think this will be massively expensive; it's only a couple of instructions in router codes I have looked at to check the packet against your IP addresses on the incoming interface. Also, it handles the incremental deployment issues I raised in a previous message. Of course, it won't work with ARP subnet rouing (unless you special case it to assume that a packet with the 'next hop' on another subnet was actually to you), but to my mind that's a feature, not a bug! 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