[RRG] Mobility, update rates & charging per update

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

Short version:  Map-encap direct support for mobility doesn't mean
                frequent updates, because the mapping change only
                occurs when a new TTR is used - which only happens
                when the mobile device moves to an access network
                ~1000 km distant from the current TTR.

                Why we don't need to worry so much about the
                maximum update rate in a push or hybrid push-pull
                system if that system charges per update - since the
                system will be self-funded and grow to whatever
                capacity the demand requires, at whatever price-per
                update the system can support.

                This removes the biggest problems of "too frequent"
                updates - as bedevils the BGP system - that they
                place a burden on people who are not deriving any
                benefit, including being paid, for each update.


Hi Tony,

In "RE: [RRG] Reactivating the RAM list?" you wrote:

>> indicating that we should drop the mobility discussion for now.

> ... And the operative words here are "for now".

OK - but I would be keen to hear from people on the list of
privately that they either understand and accept my point about
mobility not requiring frequent updates, whilst benefiting from low
latencies for updates.  Likewise I would be keen to hear any
critiques.

I think it is a really important point and no-one has yet agreed
with me on the list - or disagreed.

A guide to my recent attempts to explain this is:

   http://www.firstpr.com.au/ip/ivip/#mobile

I request that if we pause the mobility discussion for the moment,
that people go forward with the tentative notion that maybe mobility
won't involve changes every minute or hour - but only usually when
people travel large distances like 1000km.   Then, the 5 billion
mobile end-users scenario doesn't necessarily mean astronomical
update rates.


> I have every intention of returning to the topic at the
> appropriate time, but for the sake of making forward progress, it
> seems like there are some more basic issues that we can
> deal with (granularity & churn) and then revisit mobility in a
> bit.

> If, for example, we conclude that we want host level granularity
> and can support a churn of 1 nano-second, then the entire mobility
> discussion is moot.

I support host-level granularity and have some WAGs:

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

which gives about half the update rate to mobiles, with total update
rates in the few hundreds per second, which seems feasible to me -
even when whatever number (X billions - one for every person and
their dog) of mobile devices have 5 million people and dogs a day
moving 1000km or so.

> So let's decide where we are on the basic issues and then come
> back to the more complex issues.

OK.


>> I am also wary of the notion of trying to set an upper bound on
>> the rate of mapping changes, because this may involve an
>> assumption that each mapping change doesn't pay its way and so
>> causes unreasonable burdens on other parties.  That is true of
>> BGP or APT, but is substantially not the case for Ivip or
>> potentially other proposals.

> Interesting point.  I'm not quite following.  Is this is an
> intrinsic difference between push and pull, or is there something
> more?

In most practical examples I could think of, it is a difference
between push and pull.  But impractical counter-examples indicate
the difference is not actually intrinsic.

With push in the form of Ivip's hybrid push-pull, there is a unified
but decentralised, fault tolerant, set of servers called the
Launch system which sends, every second, a bunch of updates to the
cross-linked tree structured Replicator system, which fans them out
to ~x00,000 full database ITRs and query servers all over the Net.

This is bold stuff, but we are designing a new routing and
addressing architecture, so I figure it is worth going to this sort
of trouble to get the mapping out across the planet in a fast,
streamlined, robust manner.

The Launch system and quite a lot of the Replicator system is owned
and run collectively by the Root Update Authorisation Systems, each
of which is a separate commercial entity, probably for-profit.

This is described in pages 33 to 48 of:

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

All updates are initiated by end-users (or some system with the
end-user authorises to make the updates, such as a multihoming
monitoring company) and go through one of the RUASes.  Each RUAS
handles one or more Mapped Address Blocks (MABs), so each produces,
ever second, a bunch of updates for its own MABs.

End-users can choose between various RUASes (and in so doing decide
what fees to pay, which MAB their micronet address space comes from
etc.) and every update goes through one RUAS.  I am guessing their
might be one or two dozen RUASes, not hundreds or thousands.

RUASes will charge the end-users directly - if the end-users are
direct customers - or indirectly if the end-users are customers of
some intermediate Update Authorisation Service company.  The charges
will be, in part, for updates - but will also cover how much mapped
address space each end user has.  (There may also be traffic charges
for high-volume end-users where the traffic to those end-user's
micronets burdens the "anycast ITRs in the core/DFZ" which the RUAS
runs to make the MAB reachable from hosts in networks without ITRs.)

This fee per update will allow the RUASes to pay for the Launch and
Replicator systems - and help them turn a profit.

My WAGs lead to 228 updates a second - 2 million a day.  At 5 cents
an update, this is a million dollars a day, more than enough to
build and run a handsome Launch and Replicator system.

(For initial deployment, the Replicator system would use existing
stable servers, such as nameservers which were not too heavily
loaded - since the update volume would be quite light for a few years.)

People here frequently pay a cent a second to talk on a cellphone,
so I figure paying 5 cents to change mapping when mobile (after
moving 1000km or so, and so using another TTR in the new area) will
be fine.

Mapping changes for TE would be well worth 5 cents to many busy
network operators, since they give ~5 second latency control over
whether a micronet is mapped to one ETR or another.  So there is an
unknown demand there, which would depend very much on the price,
which is also unknown.

For a million dollars a day I reckon you could run most of a
fast-push system, whether it was doing 1000 changes a second at one
cent each, or 200 a second at 5 cents.

If there was demand for 100,000 changes a second, at a cent each, I
am sure there would be a way of doing it ($3.65 billion a year) -
but rates such as this are going to be difficult or impossible for
full database ITRs and query servers to process with foreseeable CPU
and RAM technologies.

By the time it happens - say 2020 - I could imagine 1000 updates a
second, on average, being a feasible.  However, I don't think we
will need this rate.  Maybe a hundred a second or so will be fine,
depending on the demand for TE changes.  The fast hybrid push-pull
system is is a streamlined system designed for this purpose, not the
inefficient BGP approach of a bunch of routers chattering to each
other with the information flowing across the network like rumours
through a crowd.

The key point is that the physical and commercial structure of this
fast hybrid push-pull system is ideally suited to charging for each
update, and so raising the revenue to run the system and to set
pricing so the actual update rate does not exceed the technical
capabilities of the system.

This means we don't have to worry so much about absolute update
rates, since we are not trying to prevent a meltdown similar to the
problem with DFZ routes and updates in BGP today.  The meltdown is
caused by more and more people adding routes, which cost a lot for
everyone who runs a DFZ router - but without any payment from the
people who advertise the routes:

  http://bill.herrin.us/network/bgpcost.html

It would be a mistake to build a push or hybrid push-pull system
with free updates, or to assume that this is how any practical
system would in fact work.


With pull, you could have a reasonably centralised source of
mapping, not unlike the RUAS idea of Ivip.  Then you could have a
small number of query servers, and each ITR could verify the
signature of the mapping replies it gets - since the ITRs could
feasibly authenticate the signatures of the small number of RUASes.

That would greatly simplify the problem of authenticating the map
change commands, because the small number of RUASes would be the
gateway to a billion or more end-users.  (ITRs can't be expected to
authenticate billions of different signatures.)

This "centralised pull" system would also be amenable to charging
for updates, and or for charging in part of the basis of the number
of requests for each mapping.

There is less need - perhaps no need - to charge for updates in a
pure pull system, since generally changing the mapping doesn't
burden any ITRs.  However, if a pull system such as LISP-ALT had
some EIDs with really short caching times, for fast response to
changed mapping, then this would be widely perceived as an
unreasonable burden on the ALT network, and on the ITRs handling
traffic addressed to those EIDs.


However, the existing pull systems (ALT and TRRP) do not use this
centralised approach.  They have fully decentralised authoritative
query servers (ETRs or nameservers respectively), each controlled
directly or indirectly by one of the billion or so end-users.

I think this will be a nightmare to run securely.  It is also an
architecture which resembles BGP in some important and undesirable ways:

1 - The changes are injected into a global system, from any point -
    raising difficulties for any one part of the network being sure
    that any mapping information injected from near or far is
    properly authorised.

2 - In the absence of some central register of what is allowed,
    there is no way of erecting a gate to improve and centralise
    authentication of mapping information.

3 - Likewise, there is no way of stopping the mapping information
    which is injected by end-users who don't pay some fee for each
    announcement, change etc.

4 - Consequently, the ALT network suffers from the potential that
    it could be swamped by a subset of end-users producing mapping
    information with very short cache times, whether or not the
    mapping actually changes much.  (In BGP, it is the changed
    advertisements which burden the whole network.)

However, it is not as bad with ALT as with BGP, since with ALT, the
more frequent requests and responses only come from and go to that
subset of ITRs which is actually handling traffic, while with BGP, a
changed advertisement could affect every DFZ router.

With pure pull, we don't need to fuss so much about update rates
(except as noted with very short cache times), so in general you
don't need to worry about charging for them, or the total rate of
change.


With a pure push, or hybrid push-pull, we do need to worry about
each change being a burden on the push network, and computationally
on the full database ITRs and query servers which receive every
change.  However, if there is a reasonably centralised gateway -
such as the RUASes in Ivip - then they can charge a small fee, and
thereby  pay for whatever push network is required to meet the
demand of the day, at that price.  So then we don't need to worry so
much about changes burdening people who don't benefit from them in
some way - which is the nature of one of the primary routing
scalability problems with BGP which we are trying to solve.

If you had a push or hybrid push-pull network without such charging,
you would have difficulties showing why anyone would build it, and
you would have to figure out either what maximum rate end-users
might  collectively drive changes into it, or some way to deter
"excessive" sending of changes, however defined.

  - 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