Subject: [RRG] Future mapping DB size, small micronets/EIDs

From: Robin Whittle <[email-masked]>
Date: Thu, 21 Feb 2008 11:46:16 +1100

Hi Scott,

In "Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4
address depletion, you wrote:

> On 2/16/08 9:14 PM, Robin Whittle allegedly wrote:
>> (or I guess /64s for IPv4)
>
> This makes no sense.  How many bits are there in an IPv4 address?

I meant IPv6.

>> so I think they are aiming their system to do "network" (many
>> IP addresses and hosts per EID prefix) multihoming, not "host"
>> multihoming.
>
> There is an authentication problem with map-n-encap and wandering
> EIDs.

(See new thread "Authentication of authority to control mapping"
concerning the questions you raise about problems with securely
controlling mapping.)

Is it true that with LISP in general, or at least with LISP-ALT,
that you not anticipating the system to be used to control the
mapping of individual IPv4 addresses or IPv6 /64s, but to be used
for some larger number of these?

If so, please give some examples of the lower limit of number of
IPv4 addresses per EID prefix - the longer prefix limit - you think
the system should be used for.

For instance, do you think LISP should be used to provide EID IPv4
prefixes longer than /24?   Or some other limit shorter than /32?
If not, I would like to understand your reasoning.

> However, there is not really a need for this anyway.  An EID
> names an interface -- a network attachment point.  It is not a
> persistent name for a device.  Session continuity (the real gist
> of the IP mobility problem you're trying to solve) does not and
> should not need continuity of IP "address" as you move.

I think that unless you have host changes, session continuity
depends entirely on persistence of the IP - address used by
applications and seen by the correspondent hosts - as the device
moves.  Traditional approaches to Mobile IP involve fancy software
at one or both ends, and usually a "home agent" router, with the
likelihood of long path lengths unless the correspondent host has
upgraded software too.

Ivip's approach to mobility is different.  The mobile device retains
its IPv4 (or IPv6) address or prefix (with Ivip, actually any
contiguous number of them, from any starting point) and the
applications run via this address.  The device gains one or more
care-of addresses in the various networks it connects to, and sets
up a two-way encrypted tunnel to a Translating Tunnel Router (TTR)
which behaves like an ETR to the rest of the Ivip system, but can
also get packets out to the Net.  This is described further in:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.html#rfc.section.4.5

Since there is a lot you can do with a single IP address, I think
the map-encap architecture should support and work efficiently with
single IPv4 address EIDs/micronets.

>> So far, Ivip is the only map-encap proposal which explicitly
>> aims to provide mobility - for networks or single IP addresses.
>> To do this, a fast push system is needed - either to all ITRs
>> in the world (pure push), or to some and to query servers which
>> answer mapping queries for nearby caching ITRs (hybrid
>> push-pull).  I think there also needs to be a notification
>> system by which the query server can send a message to an ITR
>> about updated mapping for a micronet (EID prefix) which it
>> queried recently and which has just had its mapping changed.
>
> I just don't see this scaling.  Can you put together a model of
> how you think it would work that we can put numbers into, to see
> when it melts?

I intend to do this, but the melting point depends on the technology
of the day.  By the time a billion micronets are needed, we will
have cheaper CPUs, RAM, bandwidth etc.

Can you write about how LISP-ALT or LISP-NERD could support mobility
or not?

Also, given the answer to that question, how many EIDs do you think
- as an outside but not unrealistic estimate - a LISP scheme would
ever have to support, say in 2015, 2020, 2030, 2040 and 2050?

  - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Feb 2008 10:03:40 +1300

On 2008-02-21 13:46, Robin Whittle wrote:
...
> If not, I would like to understand your reasoning.

I think we've had that conversation (at least, I was having it
with Tony). My conclusion is that the longest prefix is undoubtedly
/32 or /128, but that doesn't answer the important question of
how many prefixes need to be mapped, which depends on how many sites
need to be mapped and what is their size distribution.

> ever have to support, say in 2015, 2020, 2030, 2040 and 2050?

And to that question we've had answers in the 10^7 to 10^9 range,
depending on a lot of assumptions which are economic and sociological
as much as they are technical.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Fri, 22 Feb 2008 12:15:38 +1100

Hi Brian,

Regarding maximum length of LISP EID prefixes, you wrote:

> with Tony). My conclusion is that the longest prefix is
> undoubtedly /32 or /128, but that doesn't answer the important
> question of how many prefixes need to be mapped, which depends
> on how many sites need to be mapped and what is their size
> distribution.

While I understand the mapping data format for LISP will enable a
/32 IPv4 to be specified, I wonder whether it makes sense to have
ITRs all over the world tying to divide the IPv6 address space any
finer then /64.

To allow for /128 in the data format rather than limiting it to /64
adds another 8 bytes to every EID record, although it is going to be
very long anyway, since there will be multiple 128 bit RLOC
addresses for the ETRs.

I also think that allowing /128s will complicate the design of every
ITR, or at least bloat it or slow it down if someone really uses a
/128 EID prefix.

I am interested to know how the key LISP-ALT people envisage their
system being used.  Their notion of the end-users the system serves
isn't in the IDs, but I infer from some of what they write on the
list that their vision is a lot more like current PI space end-users
than the broad range of end-users, including non-technical
individuals with cellphones and laptops, I and a few other people
are envisaging.

>> Also, given the answer to that question, how many EIDs do you
>> think - as an outside but not unrealistic estimate - a LISP
>> scheme would ever have to support, say in 2015, 2020, 2030, 2040
>> and 2050?

> depending on a lot of assumptions which are economic and
> sociological as much as they are technical.

But what do you and the LISP-ALT folks think about mobility?  I
don't see how mobility could be provided by ALT, NERD, APT or TRRP.
I can see how it could be provided by Ivip.

Mobility between provider networks (eg. operators of different radio
networks) could add tens or hundreds of billions of dollars of value
to the Net and IP-centric cellphones, by enabling each one to have
its own micronet / EID, no matter where it is in the world.

To do this, you need fast push of some kind, and since push to every
ITR in the world (NERD) doesn't scale to these cellphone scenarios,
the only scalable approach seems to be hybrid push-pull like APT or
Ivip.  However APT currently does slow push via flooding the mapping
data around the world in a new BGP instance.  That leaves Ivip or
some other fast hybrid push-pull system.

Without mobility, I could imagine that maybe, one day, we might have
10^7 end-users who want number portability (I know people wince at
this term, but that is what people quite reasonably want and
arguably need) for their home and business networks.  Maybe 10^8 if
it became the common way of running a business to have at least one
IPv4 address which was genuinely stable, or with IPv6, a /64.

But without mobility for laptops/cellphones/video-players (whatever
these things develop into), how could the 10^9 or 10^10 figures be
credible?

In short, ALT or TRRP could handle unlimited numbers of EIDs, but
since they can't provide mobility, the demand will never be more
than a few tens of millions.

A few tens of millions of relatively static mapping information is
easy for NERD or APT to handle, so the primary (only?) argument for
ALT or TRRP goes away.  NERD or APT are better because the don't
delay any initial packets.

But NERD can be improved by allowing some ITRs to be caching ITRs,
querying a local query server wherever there is a full push ITR.  I
suggested this series of improvements on 22 January:

  ALT + NERD is inelegant & inefficient, compared to APT or Ivip
  http://psg.com/lists/rrg/2008/msg00176.html

No-one ever debated my argument in detail.

The first step of upgrading NERD makes it a hybrid push-pull system
like APT or Ivip.  Then we make it fast push rather than slow, which
enables the mapping data to be a single IP address, and removes the
reachability and multihoming service restoration decision functions
from the ITRs . . . and the system can support mobility and looks a
lot more like Ivip.

While a hybrid push-pull system can scale larger than a pure push
system, neither system copes well with end-users changing their
mapping very frequently, *unless* they have to pay a small fee for
each change.  That fee will naturally be set by market forces so it
pays for as much of the push network as needs to be paid for by the
end-users (ISPs will pay for the final stages as they run their own
Replicators to fan the mapping data around inside their networks).

Then, the more efficient the global push system, the lower the
prices and the more end-users will want to have micronets - and the
more they will be happy to change their mapping.

The physical mobility of cellphones is an immensely valuable thing.

Perhaps it is an anomaly in Australia, but the cost of making a
cell-phone typically exceeds the rate at which people can earn money
before tax.  (There are many freebie and discount plans, but many
folks need ordinary plans in which they are charged a cent a second.
 That is USD$33 an hour.)

I reckon a global fast push system can be largely funded by a fee
per update which in practical terms in general physically mobile use
is a lot cheaper than what people are paying for cell-phone calls today.

 - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Feb 2008 10:33:21 +1300

Robin,

> very long anyway, since there will be multiple 128 bit RLOC

The EID format is going to be variable length anyway, so we could
have three lengths: IPv4/32, IPv6/64, IPv6/128. Or make it
completely variable length, if redundant bits are really an issue.

> ITR, or at least bloat it or slow it down if someone really uses a

Certainly, but I think that we shouldn't exclude it by design. That
would be like repeating the classful addressing error in IPv4-RFC791.

   Brian

---

From: Robin Whittle <[email-masked]>
Date: Mon, 25 Feb 2008 20:14:25 +1100

Hi Brian,

> completely variable length, if redundant bits are really an issue.

It clearly needs to be 32 bits for IPv4.  There could be two
different classes for IPv6, but since we need one (Ivip) or multiple
(LISP, APT & TRRP) multiple full 128 bit ETR addresses for each
mapping entry/update, having two types just to save 64 bits in many
or most cases may not be worth the trouble.  Data compression might
be able to help with long strings of zeros anyway. Alternatively the
format could have the prefix length first, and then that number of
bits - assuming the rest of them were to be zero.

> would be like repeating the classful addressing error in IPv4-RFC791.

I agree.

   - Robin