[e2e] draft on IP Fast Option Lookup

[Michael Welzl]

> > - 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
case    :)
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    :)

Cheers,
Michael Welzl