[RRG] Supposed impossibility of scaling for mobility

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

Hi Dino and Joel,

In the RRG meeting (audio http://videolab.uoregon.edu/events/ietf/
where there should soon be an archive of Tuesday's meeting) you and
perhaps some other folks were extremely negative about the routing
system, in the form of map-encap, achieving mobility directly.  So
much so, that I understand you want mobility not to be a goal.

Yet I believe that a fast-push hybrid push-pull system with reliable
notification from local query servers to ITRs will give users ~5
second latency real-time control over all the world's ITRs.  Also,
this system doesn't have the delay or drop problems inherent in pure
pull (LISP-ALT and TRRP), so that's another thing we wouldn't need
to worry about when asking people to adopt it.

You seem very committed to the idea that mobility is impossible to
achieve with map-encap.

I would be interested in your critiques of:

  Scaling, Mobility & 228 mapping changes a second
  http://psg.com/lists/rrg/2008/msg00535.html

There I debunk the storage problem - a terabyte hard drive solves
every storage problem you can imagine.

I also examine how mobility would work - with TTRs (Ivip's concept
of Translating Tunnel Routers) the mapping is to the TTRs, not to
the mobile nodes.  So the mapping only needs to change when the
mobile node moves 1000km or more and it makes sense to choose
another TTR nearby.

Also, as I will write in a future message, with Internet access on
jet aircraft, you will be able to keep your TCP sessions etc. going
while travelling around the world.  This will be easier to manage
than changing IP addresses, starting new sessions via updated DNS etc.

In the above messaged, I have some very rough guesses about the rate
of updates when there are billions of mobile nodes, and I come up
with figures in the few hundreds per second.  That is perfectly
practical, I think, with a fast-push mapping distribution system
such as I detail here:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.pdf

Section 4 is the benefits of fast-push, and is much the same as in

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

which I assume you have read.

I suggest you skim over most of the fast-push-00 ID and read the
gutsy details in sections 7, 8 and 9 - pages 33 to 48.

I think that once you do this, if you still believe it is impossible
for map-encap to directly implement this new form of mobility (which
does not rely at all on current host-based mobile IP techniques),
then I think you should be able to articulate a robust critique of
my fast-push-00 draft and/or of my vision for mobility.

Furthermore, you should be able to argue strongly why no other
conceivable approach to fast, essentially real-time, control of ITRs
is possible - or perhaps why it is possible but undesirable.


I have been put a lot of work into evaluating LISP, APT and TRRP -
giving constructive criticism and suggesting improvements.

Ivip has been around for ten months now and I am keen for one or
more people to write a proper critique of its most unusual aspect -
the fast push mapping distribution system.  There are more details
to be sorted out of course, but there is plenty of meat for a critic
to chew on in the fast-push-00 draft.


The other part of Ivip's mapping distribution is the "Notify"
system.  This is with local query servers, full database and
optionally caching.  Some details of that follow, since it is not so
clearly documented elsewhere.


Also, if you remain unconvinced of the viability of this new form of
mobility, what is the maximum number of EIDs you expect LISP to cope
with, without each such EID being mobile?

My guess is a few tens of millions at the most - basically most
businesses and organisations on the planet.  Maybe a hundred million.

All the map-encap schemes can cope with that fine - the storage and
the update rate and volume.

The principle benefit of ALT or TRRP is its ability to handle
endless EIDs without burdening ITRs or adding volume of
communications to the mapping system beyond what is needed for ITRs
which actually need mapping for those EIDs.

This is great, but what is the point of unlimited scaling when you
are only ever going to have a hundred or so million EIDs?

Since ALT and TRRP can't provide mobility (at most ALT is intended
to work with the existing, unsatisfactory mobile IP techniques), I
can't see how you would ever get the billions of EIDs your system
could cope so well with.

Only Ivip could provide this form of mobility, so I think only Ivip
would be called upon to deal with billions of micronets (EIDs).  I
believe Ivip could cope with this.

My message and draft linked to above show why I think this is
feasible, desirable - and probably essential for anything as
momentous as a global system of ITRs and ETRs, creating a new class
of address space.


  - Robin


Ivip's local Notify system
--------------------------

QSDs respond to queries directly from caching ITRs (ITRCs) and ITFHs
(ITR functions in sending hosts, not behind NAT) and indirectly via
one or more caching query server (QSC).

The response contains the mapping - a single ETR address - and a
caching time, probably to be determined by the QSD.  If the QSD gets
a mapping update which affects the micronet (EID) of a response it
sent inside the caching time, it sends a Notify UDP packet to the
querier (a QSC, ITRC or ITFH). It expects to get an acknowledgement,
so it will retry if it doesn't get one.

The Notify message contains the new mapping information for this
micronet (EID).  It is not just cache invalidation.

The query contains a nonce, which is included in the response to
prevent attackers messing with the ITRCs, ITFHs or QSCs.

The Notify message contains the nonce from the original query, which
likewise secures it.

If the querier was a QSC, then it passes one or more Notify
messages, using the nonce of the original query, to whatever devices
queried it: ITRDs, ITFHs or other QSCs.

The QSDs and QSCs are always "local" - meaning inside a network, or
in a nearby network.  So they are within a few hundred km at most,
and a querier should have two or more upstream query servers it can
use.  A response should come back within a very short time - tens of
milliseconds, or perhaps a little more if there are multiple QSCs
for the query to go through before it finds a QSD.  If the response
doesn't arrive pretty quickly (maybe 50 to 100msec), then a packet
has been lost or the query server is dead - so the querier can send
a request to another query server.

This traffic is all local and with pretty short paths, so it has
little cost, little delay and is highly reliable.  This is
completely different from relying on a global query server system
such as LISP-ALT or TRRP in its initial decentralised, form.


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