[rrg] hIPv4 critique (draft)

[Robin Whittle <[e-mail]>]

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.

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.

  - Robin



hIPv4 Critique (1st draft)
--------------------------

hIPv4 is a scalable routing proposal which is neither a Core-Edge
Elimination nor a Core-Edge Separation architecture.  It uses two
additional 32 bit constructs: Area Locator (ALOC) and "Endpoint
Locator" (ELOC) to enable the re-use or global unicast addresses in
separate regions.  Upgraded host stacks and applications use an
enhanced DNS to communicate with hosts in other regions, with
inter-region packet transfer being achieved via special global
unicast addresses using the current DFZ.

hIPv4 packets contain the ALOC, ELOC and some flags in a new 12 octet
header option.  New, but relatively simple, devices at the borders of
regions can modify the packets in transit, swapping the destination
address for the ALOC or ELOC.

Unfortunately, routers in general - including those in the DFZ -
process IPv4 packets with any kind of header option in the "slow
path", which is via a much slower process than the usual rapid
handling provided by their FIB. [1]  Furthermore, they frequently
drop such packets.  Since hIPv4 relies on traffic packets using
header options, it cannot be considered a practical solution to the
routing scaling problem.

hIPv4 is a creative attempt at making a new set of IP protocols which
are based on, and are backwards compatible with, IPv4.  Multihoming
would be achieved in a manner similar to a Core-Edge Elimination
architecture by a network having two upstream providers and so having
each of its hosts accessible via the host's 32 bit IP address, which
is essentially an Identifier within the scope of one or more regions,
and either of the ISP's ALOCs.  Header options are in principle
capable of being used to extend the protocol and addressing
arrangements of IPv4, but unfortunately are not properly supported by
current routers.


[1] 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