[e2e] draft on IP Fast Option Lookup
michael at tk.uni-linz.ac.at
Fri Mar 23 11:40:24 PST 2001
> > - What do you think of the idea in general? Is it nice, or plainly a
> > useless waste of space in the IP header?
> The history of such speed hints is bad. A fast path wants to deal
> with simple things, and it is usually trivial to detect things that
> are not simple. For IP headers, I bet most implementations would do
> best by noticing whether there are any IP options at all. In this
> case, given MPLS and other tag-forwarding schemes, what's the point?
It is useless for routers which simply ignore IP options; this option
is supposed to help routers which DO support options, but only a subset
because most are turned off.
> That it must not be used if there are fewer than two other IP options
> confuses me. How many IP packets have more than 2 options?
More than 1. And not many, I suppose. It is a small aid for a rare
But it is useless when there is only one option (you don't need to
have an index for ONE entry).
> Has the list
> of possible IP options exploded while I wasn't paying attention?
I just registered a few new ones to push this draft :)
On a serious note, I DO agree that packets with more than one
option will be rare. Still, it's a possibility.
> There are other problems with options such as this. For example,
> why would hosts add them? "To make routers go faster" is not
> a reason, because the speed of routers doesn't affect a host's
> SPECMARK or other benchmark value.
Right - it's just a recommendation.
> Then there are the boundary and error conditions. For example, what
> happens if an option is mentioned in this option is absent?
This is described in the "security issues" section.
> What if there
> are 2 Fast Option Lookup options or if another option precedes it?
This should not be the case according to the draft. But I agree that
it should be discussed (actually, another option preceding it won't
cause much trouble - it's just inefficient).
> Finally and far more important, if you want to design such things,
> it's best to start by designing a faster router in private.
> Only after
> you have some experience with what makes a router (or
> anything) faster is
> it wise to consider publishing an RFC instructing other people.
Designing a router is not an option for me.
I trust in the IESG to prevent me from publishing an absolutely
pointless RFC, though :)
More information about the end2end-interest