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