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

[Patrick Frejborg <[e-mail]>]

Hi Robin,

your critique is valid, I did found some more papers around the usage
of options.
Architecturally it would have been a clean approach to use options,
but in the real world that is not much of an option...

So thanks for pointing this out for me!

It took me back to the drawing board and I created a new header so
that the IP header will be 20 bytes and stay in the fastpath though
there are some extensions added by the endpoints
http://tools.ietf.org/html/draft-frejborg-hipv4-05
The extensions are no longer in the option field, instead a real shim
header is created that the hIPv4 endpoints/nodes will identify by a
new protocol number in the IP header - the upper layer protocol (e.g.
transport) number can be found in the shim header. This shouldn't
upset the intermediate legacy routers, or does it?

About the 32-bit address space, I think it is good enough. In the
pre-RRG world it isn't but here at RRG two issues has been discussed
quite a lot that changed my world quite radically, that is, the
core-edge separation/elimination and the decoupling of
identifier-locators.

-- patte

On Thu, Feb 11, 2010 at 2:20 AM, Robin Whittle <[e-mail]> wrote:
> 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
>