Re: [RRG] Re: Supposed impossibility of scaling for mobility

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

Short version:   Churn rates:  Some mapping systems involve charges
                 per update, so the system will naturally finance
                 itself and push the technical limits and costs so
                 there is never a situation where excess mapping
                 changes adversely impact someone.

                 (While this is unlikely to be absolutely true,
                 it could be true to a substantial extent.)

                 High churn rates are more a problem for a
                 system where each change creates burdens for
                 others which the generator of the change never
                 pays for - for instance with BGP and APT.

                 So perhaps the concept of maximum churn rate
                 could be left more open for a scheme which promises
                 to largely fund the cost of the churn by a fee
                 per update for end-users.


                 Granularity: single IP addresses should be the
                 technical limit, even if the scheme is not intended
                 to be used in this way.

Hi Tony,

You wrote, in part:

> Let me see if I can rephrase the discussion. The mapping function
> will necessarily operate at a given maximum granularity and
> maximum churn rate.

LISP, APT, Ivip and TRRP could all go down to single IP addresses or
/64s in IPv6 without any fuss.  While I don't support going further
than /64 in IPv6, I agree with Brian Carpenter that the protocols,
mapping data specification etc. should not preclude specifying the
size of a micronet (EID prefix) down to single IPv6 addresses.

While I think there could be a variety of perspectives on the finest
granularity a map-encap scheme should be used at, I can't imagine
any perspective being strong enough to preclude the mapping data
being specified down to single IPv4 or IPv6 addresses.

Also, no matter what people may think now, I am convinced that a
very common use of a successful map-encap scheme will be to provide
single IPv4 addresses and single /64s in IPv6 for end-users.  Those
may be networks of a business or organisation, or they may be for a
single laptop, cellphone etc.

Regarding granularity, I believe the system should and will be used
for single IPv4 addresses and /64s.


> Whatever levels we choose to support in the architecture, the
> Connexion example shows that people *will* use things
> for some form of mobility/portability/migration.

The Boeing Connexion geosynchronous satellite in-cabin WiFi system
is well described here:

   http://www.nanog.org/mtg-0405/pdf/abarbanel.pdf

and its unfortunate demise is discussed at:

   http://www.slate.com/id/2144186/

Yes - end-users will use the map-encap scheme for mobility too!
Even if the finally deployed scheme is nowhere near as suitable for
mobility as I intend Ivip to be.


> Given that a defined mapping needs to define the granularity 
> and churn rate, that completely bounds how much mobility can
> be supported directly by routing.

I understand the desire to set some upper limit on the churn rate,
but I think there may be an assumption in that discussion that the
system has no way of charging for each update.  BGP, APT and
probably LISP-ALT and TRRP have no such mechanism, because the
mapping changes are injected into the system from all over the
place.  These systems (APT at least, see message 746) may also
suffer from problems authenticating the change messages.

The churn rate doesn't matter with ALT or TRRP since they are pure
pull systems - unless these schemes add some kind of Notify system
(carefully directed push) or unless the churn rate leads to very
short caching times forcing ITRs to continually re-request mapping
information.

Ivip and perhaps NERD has a more centralised source of mapping - so
there is a readily available means of centralising the
authentication of mapping changes, and also for charging for each
update.

With Ivip, I aim for a fast, efficient, push system - to as far into
networks as operators choose to place their full database ITRs and
query servers.

The idea is that the end-user will pay, one way or another, per
update - and probably in other ways for their mapped address space.
 The idea is firstly that the fast push system is efficient and
highly scalable, and secondly that whatever number of updates it is
carrying (the high churn rate) it does so on a profitable basis.

So as the system grows to massive volumes of updates (massive churn)
it remains functional and viable at all times, with no end-user
placing an unreasonable burden on any other party.  If the technical
limits are really pushed, then the price goes up (or at least
doesn't continue to fall) so people think more carefully before
changing their mapping.  Then the churn rate automatically remains
within reasonable technical and commercial bounds.

I can't tell you what the maximum update rate the Ivip fast-push
system would cope with in 20 years time.  I do have some WAGs about
it not needing to be more than a few hundred updates a second, even
with billions of end-users, most of them using the system for
mobility.  Although this is more than BGP's current rates, this
seems perfectly practical, since it is far more streamlined system
and involves simpler data than BGP advertised routes being
propagated from one router to another.

If the Ivip system is also used intensively by a small number of
high-traffic end-users for real-time TE on a 5 second by 5 second
basis, that is great too - those people will be paying for the
changes and so will help to finance the fast push system.

So when considering churn rate, I think it is important to
distinguish between a BGP-like or APT-like flooding system with no
revenue per change - which suffers from the exact same free-rider
problem we are trying to overcome with the bloat in the DFZ routes
and updates today - and a system such as Ivip where the end-user
making the update does pay partially or entirely for the burden they
place on the mapping distribution system.


> Or, in other words, we should drop the mobility discussion for
> now, deal with the granularity and churn issues, and then see if
> we are happy with the bounds that that imposes on mobility.

I agree with Bill:

> Do we have a consensus on what target numbers for granularity and
> churn could support mobility directly in the routing system? If
> not, I submit that we should continue our tangent long enough to
> get them.

I think it is productive to continue to explore how a map-encap
scheme could be used for new approaches to mobility.

A global map-encap system is an extraordinarily powerful tool which
has not been anticipated by the mainstream mobile IP folks.

My previous messages in this thread argue that mapping changes do
not need to be used in the most obvious manner: changed mapping each
time there is a new care-of address.  Anyway, those CoAs will often
be behind NAT, and so can't be reached by the ITR.

I have also tried to show that there is no extra architectural
complexity to support mobility in Ivip.  The mobile component of the
churn rate will however affect the update volume and workload of
full database query servers and ITRs.

The map-encap scheme enables a new form of mobility which involves
relatively few mapping changes - so one shouldn't assume mobility
opens the floodgates to billions of devices needing a mapping change
every time the device moves from a WiFi system in a cafe back to the
more expensive 3G system in the street.

So I think it is best to discuss mobility and its potentially lower
than expected demands on the churn rate, while discussing churn
rates and whether the proposed system supports per-update charging.


> |> If you don't want to deal with it under the label of mobility, then
> |> we can change it to "the maximum amount of churn that any single
> |> player can inject".
> |
> |or *should* inject.  There is a tradeoff here.  Supporting churn by
> |individual nodes is one dimension along which to evaluate an
> |architecture.  The routing architecture, as a whole, may be
> |significantly more robust by cutting off the churn it allows at some
> |threshold.  (But you know that)
> 
> Indeed.  In fact, I would argue that the architecture should have a
> well-defined, strongly enforced churn rate, for safety reasons alone.

As long as updates pay their way in the mapping distribution system,
I am not sure we need to set a maximum update rate now.  We need to
anticipate what the rates may grow to, but as long as the system
pays for itself, then the costs and rates will nicely match the
technology of the day.


 - 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