Re: problems with RFC 1063

jnc@PTT.LCS.MIT.EDU (Noel Chiappa) Wed, 29 November 1989 04:48 UTC

Received: from decwrl.dec.com by acetes.pa.dec.com (5.54.5/4.7.34) id AA16602; Tue, 28 Nov 89 20:48:09 PST
Received: by decwrl.dec.com; id AA02721; Tue, 28 Nov 89 20:48:03 -0800
Received: by PTT.LCS.MIT.EDU id AA13332; Tue, 28 Nov 89 23:46:37 EST
Date: Tue, 28 Nov 89 23:46:37 EST
From: jnc@PTT.LCS.MIT.EDU (Noel Chiappa)
Message-Id: <8911290446.AA13332@PTT.LCS.MIT.EDU>
To: craig@nnsc.nsf.net
Subject: Re: problems with RFC 1063
Cc: MTU@nnsc.nsf.net, mtudwg%decwrl.dec.com.jnc@lcs.mit.edu

	I'd second what Craig said; what wrong with 1063?

	First, options are certainly cheaper than fragmentation. Also,
I can imagine ways (i.e. I have a patent filed but it hasn't cleared
yet, so I can't tell you how it works) to build routers that forward
packets with options just as fast as those without. So, I don't think
you shoulkd make architectural decisions based on the impact on router
performance; just design the best mechanism!
	Parentetically, in conventional routers, any option (even if
it's not interpreted by each router) is still expensive, since any
time there are *any* options you have to look at them all to make sure
none of them is one you *do* have to deal with.

	Second, as far as the bit in the IP header goes, there are a
number of proposals to use it in congestion control (e.g. the DEC
scheme), and from my perspective (as Area Director) that potential use
is far more critical (in addition to needing that bit far more often,
making the occasional use for MTU a better bet for the option), so I'd
be unlikely to support using that bit for MTU.
	Sorrreeeeee....... just trying to do what's best....

	Noel