Re: My comments

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

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA24330; Sun, 10 Dec 89 19:22:43 PST
Received: by decwrl.dec.com; id AA24220; Sun, 10 Dec 89 19:22:40 -0800
Received: by PTT.LCS.MIT.EDU id AA25559; Sun, 10 Dec 89 22:22:04 EST
Date: Sun, 10 Dec 1989 22:22:04 -0500
From: jnc@PTT.LCS.MIT.EDU
Message-Id: <8912110322.AA25559@PTT.LCS.MIT.EDU>
To: sytek!kzm@hplabs.hp.com
Subject: Re: My comments
Cc: jnc@lcs.mit.edu, mtudwg

	Keith, I think your analysis and summary is right on the nose. I
guess I have a couple of 'off the cuff' (i.e. I may be full of s^&*)
engineering taste reactions to your summary.
	While it's true that something requiring an extra option to be
recognized and acted on by routers will take a while, it will take just
as long (and probably longer) to get all the *hosts* modified to recognize
an option. Remember, whatever scheme is devised must work *reasonably* well
in the presence of hosts and/or routers which have not yet been upgraded to
recognize it. This argues for something (possibly kludgy) using existing
things that everyone is guaranteed to have (such as the idea of sending just
a large first fragment and looking at the 'fragment time exceeded' messages
that come back).
	However, I always favor doing the 'technically right' thing over the
'expedient' thing, if at all possible. However, in this case, I'm not sure
how useful that is, since in the long run the Open Routing architecture will
allow you to discover the MTU of a route (or even ask for a route with an
MTU larger than the shortes). However, the 'long run' could be quite a while.
	Where does this leave me? I'm not sure, unfortunately. I guess my
initial reaction is that I could see living with any of the three schemes;
1063, RF option, and sending only the first fragment; each has advantages
and disadvantages in terms of deployment. Does any of them give us some
capability the other does not, or cost a lot less in operation?

	Noel