[RRG] Map-encap space for "server" vs. "client" end-users?

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

Hi Bill,

In "Re: [RRG] Why delaying initial packets matters - complex web
pages & real-time P2P" you wrote:

> It seems to me that one assumption which has run heavily through
> this thread is that man-n-encap would entirely replace the
> existing system where the EID and LOC are the same. It strikes me
> that not only is this unlikely, it would be undesirable as well.
>
> I won't spend a lot of time on why outright replacing BGP is
> unlikely. Suffice it to say that anything the size of the
> Internet has a great deal of inertia and no map-n-encap scheme
> discussed so far has enough punch behind it.

I intend Ivip's address space to be so attractive to end-users (who
want or need multihoming, TE and portability) that it will be very
widely adopted - ideally becoming the usual form of address space
for end-users.  I think we need the new map-encap space to be
attractive to end-users large and small, established and new:

  http://psg.com/lists/rrg/2008/msg00275.html

None of these map-encap schemes replace BGP.  They rely on the BGP
system for directly handling the "RLOC" address space which is used
by all ISPs and by end-user networks which for one reason or another
are not using the map-encap scheme.  All traffic between ISP
networks still relies on the BGP system.  The map-encap scheme
provides a way of dividing the address space down into smaller
chunks (micronets AKA EID prefixes), each individually handled by
any ETR (Ivip) or one or more ETRs (LISP and APT) in the world.

Each such division does not directly burden the BGP control plane,
other than to the extent to which Mapped Address Blocks (MABs) are
advertised in BGP, as they are in Ivip and LISP with "Proxy Tunnel
Routers".  The idea is that each MAB provides many micronets for
many end-users, so this burden on the BGP control system will be
small compared to the burden of serving that number of end end-users
with conventional "RLOC" space which is managed by BGP alone.


> I will spend a couple paragraphs on why a hybrid system is a
> desirable outcome.

I am not sure what you mean by "hybrid", but I think you mean some
end-users are better off with the current BGP-managed approach to PI
space while others are better off, or will be encouraged/forced to
use map-encap space.  This is very different from what I am
proposing with "hybrid push-pull" (APT and Ivip) and from the NERD
concept of "hybrid" in which ITRs are full database for some subset
of the EID space and rely on a global query server system to be a
caching ITR for the rest of the EID space.


> There are relatively few scenarios in which a client machine
> derives a benefit from a static IP address assignment. Mobility,
> at least with respect to long-lived connections. The occasional
> firewall admin where inbound access to a resource has been
> restricted by source IP address. Not a whole lot else.

OK - in part because widely used client applications are adapted to
operating behind NAT, where the public IP address may change from
time to time, as with the user's DSL/cable modem getting a new address.

But I think it would be best to have a map-encap scheme which didn't
require distinctions to be made between different methods of using
the address space, other than the dichotomy between space used by
ISPs for ETRs and other functions (including for PA space) and for
all other organisations and individuals ("end-users").


> Given a choice between a mild slowdown and the temporary
> assignment of an IP address from a highly aggregated pool, most
> clients would elect to use the temporary assignment.

There are more choices than between ALT (mild slowdown) and pushing
the "client" subset of end-users into dynamic addresses from RLOC space.

I am sure there are many end-users, large and small, who want
stable, portable, multihomable address space to run both servers and
client hosts on.  So trying to decide which end-users are "server"
end-users and which are "clients" would be difficult or impossible.

For instance, there is likely to be a huge demand for mobility with
persistent connections due to the device/network retaining the same
IP address no matter which network it uses for its care-of address -
with both IPv4 and IPv6, with generally optimal path lengths.
Cellphones and mobile PCs (probably the same thing in the future)
are the most obvious use for this.  Ivip is intended to provide this
form of mobility.


> Servers are a whole other can of worms. There are spam filters
> which block and permit by IP address. There's lots of crappy
> software which doesn't respect DNS TTLs. Renumbering servers is a
> difficult and fault-ridden process. Given a choice between an
> extra delay equivalent to a DNS lookup on every request and
> having to renumber, more than a few server administrators would
> choose the extra delay... Especially for email servers and other
> devices that move data in bulk where the delay simply doesn't
> matter.

Yes, I think for email servers the initial packet delay is not a
problem.  For web servers, game servers etc. having a bunch of
these, especially for a bunch of customers, would be extremely
disruptive and expensive for the end user - the hosting or
self-managed server company - and their customer end-users.

However, given the choice of keeping or attaining conventional space
(BGP-managed "RLOC" space) and changing over to a map-encap type of
address space which involved almost any perceivable degradation
(reliability, initial packet delay etc.) I think most existing and
new "server hosting" companies would avoid the new system like the
plague.  Competitors with the original, authentic, good-ol-days RLOC
space would be pointing out the superior responsiveness of their
servers compared to the slower nature of the new-fangled plastic
map-encap space.


> The conclusion, it seems to me, is that the desirable outcome is
> a hybrid system in which a fellow in Operations can consider both
> PI space and Fast space, and then choose the one best suited to
> his particular application.

The RRG needs to decide what sort of map-encap scheme to recommend
to the IESG for engineering development.  I assume we will be aiming
for consensus that one scheme alone should be developed.

I think the aim is to have a map-encap scheme which will be as
widely adopted by end-users as possible.  This includes end-users of
all sizes, existing and new.  Ideally, virtually all end-users would
use the space, leaving only the ISP's spaces (and the MABs) directly
managed by BGP.

I don't think any of the current schemes make conventional PI space
intrinsically less attractive.  However it is becoming increasingly
hard to obtain due to the IPv4 address shortage and concern about
the burden it places on the DFZ routing table.

I assume that by "Fast space" you mean the map-encap type of space.
 I don't think it will be "faster" than conventional RLOC space, in
terms of packet delivery - but it would probably be faster and
certainly cheaper and easier to alter its management for
multihoming, TE and portability.

The choice may be between:

  LISP-NERD  Full push - looks hard to sustain full database push to
             every ITR on the planet in the long term.

  LISP-ALT   Full pull - looks complex and unreliable, with long
             paths and delays for queries == initial traffic
             packets.  (The ALT network could be tweaked with more
             meshiness to reduce typical, but not worst-case, long
             paths due to the current focus on address aggregation
             over geographically short paths.)

  LISP-ALT with caching.  Typically improved mapping response times
             but is initial packet delivery any faster?

  Mix of NERD and ALT - but why bother with ALT if you can push the
             full database to even a handful of ITRs.  Put a query
             server at those sites and then the ALT network is not
             needed.

  TRRP       http://bill.herrin.us/network/trrp.html
             Pull via a DNS-like global distributed query server
             network.  Instead of ALT's circuitous path problem,
             TRRP has more direct paths to the query servers - but
             a similar delay problem arises due to the likely need
             for multiple recursive queries to find the
             authoritative query server.

  APT        Hybrid push-pull.  Full database ITRs and query servers
             are integrated into a Default Mapper.  All
             participating ISPs have a few of these, with a slow
             push scheme (separate BGP-like flooding system).  No
             support for non-upgraded networks (Ivip's anycast ITRs
             in the core == LISP's Proxy Tunnel Routers) - so it is
             not incrementally deployable.

  Ivip       Fast push (I will write an ID on this ASAP) to full
             database query servers and ITRs located anywhere - so
             it is highly flexible.

             Caching ITRs and optional caching ITR functions in
             sending hosts (not behind NAT) access the local query
             server(s) and get responses faster, less expensively
             and more reliably than with a global query server
             network (TRRP or ALT).   Optional caching query servers
             can be used as well, which query the full database
             query servers directly, or through other caching query
             servers.  Query servers respond with mapping
             information and a cache time, and send notifications to
             the querier (ITR or caching query server) if the
             mapping changes in that time.

             Incrementally deployable, fast mapping (also an ITR
             can let an initial packet go - it will be forwarded
             to a full database ITR) and capable of supporting
             a new form of mobility.

None of these are "faster" than current PI space for handling
packets, but those which rely on a global query server network will
be significantly slower with some initial packets.


> In other words, whether you favor LISP or IvIP or TRRP, your
> system should be designed as a supplement to BGP, not a
> replacement. A supplement which serves to enable PI space.

End-users with current PI prefixes could convert them into
individual MABs with Ivip (or use the space with any other scheme).
 Then, if they had been advertising the space in multiple longer
prefixes, the space could be a single MAB advertisement under BGP,
reducing the size of the DFZ routing table.  Then they could split
it up into as many micronets as they like, which they can't do at
present, due to the 256 IPv4 address granularity limits of the BGP
system.

I have been using "PI" to refer to conventionally BGP-managed PI space.

The new map-encap scheme provides Provider Independent space too, so
if you include map-encap-managed space as part of "PI", then I think
all the schemes accord with your last two sentences.

  - Robin

--
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