[RRG] Why delaying initial packets matters

[Robin Whittle <rw@firstpr.com.au>]

In "Re: [RRG] Re: Aggregation Implies Provider Dependence (LISP-ALT)
& Ivip dependencies too", Brian Carpenter wrote:

> However, user expectations are of a noticeable delay between
> dialling a phone number and hearing the ringing tone. So e2e
> lookup solutions to both number portability and roaming are
> tolerable. If we're prepared to tolerate such a delay in initial
> identifier-to-locator lookup, why are we having this
> conversation? (And note that Mobile IP effectively *does* use
> such a solution.)

A scheme such as ALT will also delay some of the DNS (identifier to
locator) lookups, since some DNS servers will be on EID space which
the ITR has no mapping for.

I think there at at least two reasons we should be concerned about
the delay problems inherent in a map-encap scheme which depends on
any kind of global query server network (LISP-CONS, LISP-ALT or Bill
Herrin's TRRP):

1 - Great reluctance to introduce or impose any new architecture
    which further delays the establishment of communications.

2 - Concern that if the new kind of address space involves
    extra delays of any measurable kind - especially when they
    are perceptible by end-users - that this will be a serious
    and perhaps fatal barrier to the widespread adoption of the
    new kind of address space.

So even if we decided these delays should be acceptable for all
future end-users we also need to consider how end-users will
actually feel about these delays.

Consider how much money end-users spend on web servers, with fast
CPUs, high peak data rates to the Net etc.  This is so the browsing
user finds the website nice and fast.  Part of it is also that the
end-user feels good about their web server.

This may seem a trivial, non-technical, matter - just as purchasing
flashy new prestige automobiles is not really a technical matter,
since they all have to travel at the same speed on the roads.

The way end-users feel about their network is important.  Since we
need the new architecture to be widely - ideally ubiquitously -
adopted, we need to ensure that the new kind of address space feels
good to future end-users.  These will be a much wider range of
organisations and individuals than currently run multihomed networks.

Consider a business end-user choosing between two types of address
space - such as for their web server, or for their desktop computer
users in the office.

One type is ordinary PI space as we have it today, directly handled
by a BGP advertised prefix.  The other is from the map-encap scheme
and is known to involve somewhat slower responsiveness due to the
new architecture being based on ALT etc.

It will be difficult to convince end-users to pay money (including
less money) for the slower type of address space.

This also applies indirectly if the end-user is not seeking their
own address space as such, but is purchasing services on a host
which uses one type of address space or the other.

I assume we want hosting companies to use the new map-encap type of
address space.

If there is any significant (however defined) measurable loss of
responsiveness due to initial packet delays in the new type of
address space, the hosting companies would avoid it like the plague.
 They would promote their servers as running on genuine PI address
space, not that second-rate, cheap, often a little slower to
start-up, type of LISP-ALT address space.


LISP-NERD, APT and Ivip avoid these delays.  Initial packets are
either tunnelled directly by a full database ITR (NERD and with
ITRDs in Ivip, or the Default Mapper in APT) or they are tunnelled
very rapidly by a caching ITR (Ivip), since the caching ITR can get
a response from a local Query Server within a few milliseconds or
tens of milliseconds.  (Ivip also allows the initial packets to be
passed on to where they will be handled by a full database ITRD and
tunnelled without delay - the caching ITRs handle all the traffic as
soon as they have the mapping data.)

For us to choose a new map-encap architecture which relies on a
global query server network, with its inherent initial packet
delays, administrative and security difficulties, and its greater
vulnerability to packet loss I think we we would need to be
convinced that the benefits of such a scheme are absolutely
essential, and that therefore we have to put up with
the new type of address space being slower for end-users.

As far as I can see, the sole benefit of ALT, CONS or TRRP is that
at some stage in the future when the mapping database might grow to
immense proportions, these architectures will still be feasible -
while any alternative architecture (which involves multiple copies
of the database being pushed and stored to multiple devices around
the Net) would become technically or economically prohibitive.

The alternatives (NERD, APT and Ivip) all involve sending the
database to multiple full database query servers and/or full
database ITRs all around the Net.

Are there any major arguments for ALT (or CONS or any other global
query server system) other than that it can scale to indefinitely
large database sizes, while any architecture involving local query
servers (supposedly) could not handle such a large database?


Later, I will post an argument about why it is, and always will be,
practical and desirable to push even the largest imaginable mapping
database to a system of local query servers and/or ITRs.


  - Robin         http://www.firstpr.com.au/ip/ivip/


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg