Re: [rrg] hIPv4 critique (draft = final)

[Robin Whittle <[e-mail]>]

Hi patte,

Thanks for your reply.

As far as I know, there's nothing to change about my critique, so
unless you or anyone else can suggest something, the version at
(msg05990) can be used for the RRG Report.

I didn't look in detail at the Fransson and Jonsson paper, but as far
as I know it is reasonable to assume that any header option will
cause the packet to be processed by the slow path.  Other people on
this list - such as the LISP folks, who I think helped design the
routers most widely used in the DFZ - would be able to provide a more
authoritative answer.

Assuming you can't use a header option, I don't think your proposal
can work, since you need a way of adding extra information into all
packets in a way which will not upset either routers or non-hIPv4
hosts.  The only alternative to a header option seems to be, as you
suggest, a UDP header followed by some information you want to
include - the flags, ALOC and ELOC.  But then the packet would not be
recognised by non-upgraded hosts.

So as far as I know, there's no way of doing what you want - or any
other such approach to introducing a new packet format for extended
IPv4-based addressing which would not upset non-upgraded hosts and
routers.

If IPv4 had been designed with a theoretical 48 or 64 bit address
range, and with the header only containing the lower or upper 32 bits
of this, to be zero-extended to the full length by recipients, then
stacks. APIs and applications could have been ready to handle an
extended header format, or a new header format (IPv5?) when the need
arose to go beyond 32 bits.  Likewise, routers could have been ready
to cope with the new arrangements.

But that was nearly 30 years ago, 8 bit and the newer 16 bit
microprocessors - and the excellent new 32 bit 68000 (with 16 bit
data bus) - were running at 8MHz.  There were slightly more than 2^32
people, and the original coax-cable 10Mbps Ethernet standard had just
been published, with 48 bit MAC addresses.

If we are still boxed in by IPv4's lack of upgrade path in ten or
twenty years, I wouldn't be surprised.

That said, we should recognise what a good design it was, since with
DNS and the BGP-based core routing system, the system works very well
(although in some ways, only just works) decades later, with billions
of users and (I guess) a billion or so IP addresses in active use.
Imagine if there had been no such system.  We might have had to adapt
Microsoft, Apple or Novell networking to a global scale - or
implement a globally agreed subset of OSI.

  - Robin


> 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