[e2e] draft on IP Fast Option Lookup

[Vernon Schryver]

> From: Michael Welzl <michael at tk.uni-linz.ac.at>

> I would really appreciate feedback on this draft, especially from
> the router vendor folks   :)

I'm not a router person, but I have designed and implemented commercial
stuff that peeked at headers and chose faster or slower paths.


> - 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?

That this option is variable length means that it is among the
most complicated IP options, which is an odd characteristic for
something that is intended to help things go faster.

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?  Has the list
of possible IP options exploded while I wasn't paying attention?

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.

Then there are the boundary and error conditions.  For example, what
happens if an option is mentioned in this option is absent?  What if there
are 2 Fast Option Lookup options or if another option precedes it?


> ...
> - Where else should I discuss this? Would the NANOG list be appropriate?

Long ago, there was some overlap between those who buy and operate
routers and those who design and implement things.  Today, the camps are
quite separate.  (Never mind those whose resumes say they have "implemented
TCP/IP in the Enterprise".)  Too many operators tend to be uncritical of
sales blarney about the current magic speed pill.  Previous pills included
"ASCI" and "RISC."  "RISC core" and "DSP" are more recent.

It is possible to sell such features in forums such as NANOG, but not
profitably.  Features that cannot be detected by watching the wire
are ignored in the long run.  A router that does the obvious and uses
a fast path for IP headers with no options and a slow path for IP
headers with any option would be indistinguishable from a router that
used a hint like this.  Sooner instead of later, designers omit those
magic sales pill, usually without telling their own salescritters and
customers and always without telling the competition.


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.
The weaknesses in the RFC's that tried to instruct how to make compute
the TCP checksum faster are classic examples of that syndrome.


Vernon Schryver    vjs at rhyolite.com