Re: [rrg] hIPv4 critique (draft)

[Patrick Frejborg <[e-mail]>]

Hi Robin,

thanks for taking the time to review, some comments inline

On Wed, Feb 10, 2010 at 2:15 AM, Robin Whittle <[e-mail]> wrote:
> Hi patte,
>
> Below is a draft critique of your hIPv4 proposal.
>
>  http://tools.ietf.org/html/draft-irtf-rrg-recommendation-04#section-5.1
>  http://tools.ietf.org/html/draft-frejborg-hipv4-04
>
> Please let me know your comments and I will post a V2 version to the
> list.
>
> The bad news is that unfortunately, as far as I know, it is not
> practical to use IPv4 header options in traffic packets traversing
> the DFZ.  According to what I have been told in the past by people
> who I think are knowledgeable in this field, and according to this
> research:
>
>  End-to-end measurements on performance penalties of IPv4 options
>  Fransson, P.; Jonsson, A.
>  Global Telecommunications Conference, 2004. GLOBECOM apos;04. IEEE
>  Volume 3, Issue , 29 Nov.-3 Dec. 2004 Page(s): 1441 - 1447 Vol.3
>  10.1109/GLOCOM.2004.1378221
>
>  http://www.sm.luth.se/csee/csn/publications/end_to_end_measurements.pdf
>
> most routers process such packets on the "slow path" with software.
> The last sentence in the abstract is:
>
>  From the analysis it can be concluded that there is a slight
>  increase in delay and jitter and a severe increase in loss rate.
>
> Since your proposal relies entirely on a new IPv4 header option, as
> far as I know, it can't be practical as a solution to the routing
> scaling problem.

Yes, this is indeed very bad if the hIPv4 packets goes on the slow
path - a serious flaw

But what I had in mind is very specific option, that is option 17 -
Extended Internet Protocol, RFC1385 and the value is 0x8A.
So it is actually not a new option, it is something that has been
defined back in 1992.

It is for me unclear if option 17 has been tested in the report you
mention above, from the report:
"Both O-packets and N-packets are UDP packets with payloads
consisting of a unique sequence number (32 bits) and the
send time, ts, (64 bits). O-packets have the IP header length
set to 6 words and bit 160 to 191 (i.e., the options) in the
IP-header set to 0. Setting the first octet among the options to
0, should be interpreted as “end of option list” and should not
require any processing by routers"

Does 0x8A goes into that or not?

The study seems to test different patterns randomly and not
distinguish between option patterns, are there any studies regarding
only IP option 17?

Since 0x8A is defined and as long the router doesn't support EIP it
shouldn't take those packets from the fastpath and punt them to CPU of
the router - it is something the legacy router should ingnore and just
forward to the next-hop. That is the theory, what about real life
implementations - have the ASIC designers taken into account IP option
17 or not?

If somebody has insight on this please educate me, thanks!

Of course, I should have mentioned option 17 in my draft....sorry for
my bad writing!

>
> I didn't read all your proposal, because I want to read and critique
> others as soon as I can.  I think it is a worthwhile project to try to
> find a way that suitably upgraded hosts can break out of the barriers
> imposed by IPv4's 32 bit address space.  I don't think anyone has a
> practical way of doing this.  It seems that header options can't be
> part of any such arrangement.
>
Well, if option 17 is also sent to the router's CPU you could always
create another header to get around the problem - use a UDP-based
"shim" header :-)
But it would be first nice to know how the FIBs are implemented
regarding this specific option...

-- patte