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 1989 23:46:37 -0500
From: jnc@PTT.LCS.MIT.EDU
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
- problems with RFC 1063 Craig Partridge
- Re: problems with RFC 1063 Steve Deering
- Re: problems with RFC 1063 Noel Chiappa
- Re: problems with RFC 1063 Jeffrey Mogul