Re: problems with RFC 1063

mogul (Jeffrey Mogul) Wed, 29 November 1989 18:42 UTC

Received: by (5.54.5/4.7.34) id AA00700; Wed, 29 Nov 89 10:42:42 PST
From: mogul (Jeffrey Mogul)
Message-Id: <>
Date: 29 Nov 1989 1042-PST (Wednesday)
To: jnc@PTT.LCS.MIT.EDU (Noel Chiappa)
Cc: mtudwg
Subject: Re: problems with RFC 1063
In-Reply-To: jnc@PTT.LCS.MIT.EDU (Noel Chiappa) / Tue, 28 Nov 89 23:46:37 EST. <8911290446.AA13332@PTT.LCS.MIT.EDU>

	    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!

Well, I don't think we can simply ignore the impact on router performance,
and I would be loathe to impose a standard that implied that for the
next 17 years, everyone is going to have to buy Proteon routers :-).
On the other hand, I think it's reasonable to assume that
	(1) these options won't be sent so often as to seriously
	degrade throughput
	(2) processing an extra option is cheaper than fragmenting
	that same datagram (am I right?)
	    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....

I sent a message to Jon Postel asking for an advisory ruling, but
I've received no response.  I assume that his opinion would depend
strongly on yours, so unless someone wants to try to convince Noel
that we should be granted this bit, I propose that our further discussions
assume that we cannot have it.  (Sorry, Steve.)  That still allows the
possibility of using a new IP option as a "Report Fragmentation" flag.
	    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.

Clearly. (Too bad an IP packet doesn't have two different bags for options,
one for routers and one for end-hosts.)  Just as clearly, an option that
a router has to understand and perhaps modify is going to be more
expensive than one which it simply has to recognize as skippable.  Of
course, once you've landed in the slow path, it probably doesn't matter
that much what else you get stuck doing.