Re: rfc 1063 and intermediate routers

jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Mon, 11 December 1989 16:18 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA02435; Mon, 11 Dec 89 08:18:55 PST
Received: by decwrl.dec.com; id AA06327; Mon, 11 Dec 89 08:18:35 -0800
Received: by PTT.LCS.MIT.EDU id AA27518; Mon, 11 Dec 89 11:18:01 EST
Date: Mon, 11 Dec 89 11:18:01 EST
From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa)
Message-Id: <8912111618.AA27518@PTT.LCS.MIT.EDU>
To: craig@nnsc.nsf.net
Subject: Re: rfc 1063 and intermediate routers
Cc: jnc@PTT.LCS.MIT.EDU, mtudwg

	Craig, that algorithm doesn't work if you have two non-knowing routers
connected by a network with a very small MTU; neither the router before or
after the pair knows about the small MTU. (That was one of the algorithms I
discarded.) I thought about adding something like that as an optimization to
my algorithm, but you have to be able to guarantee that there is at most one
intervening router, and I couldn't think of a good one. Making a copy of
the hop count might work, I suppose. Still, is the optimization worth it
if we expect the option to be widely deployed quickly?

	Also, I think Steve's point about the costs of fragmentation not
being excessive is a good one.
	Still, I think we need to look for a mechanism that will work OK (i.e.
produce smaller packets rather than fragmented packets) if it encounters a
host or router which has not yet been upgraded. Schemes that use fragmentation
look more attractive to me now because of this.

	Noel