Subject: [RRG] Why not take address depletion issue into account

From: Xu Xiaohu <[email-masked]>
Date: Mon, 18 Feb 2008 11:02:17 +0800

If I understood correctly, LISP, ivip and other similar proposals are mainly
based on one assumption: host should not be changed because the cost of host
change is believed to be much larger than that of router change. At least,
the recent discussion about the tradeoff between initial packet delay/loss
and the scalability of the mapping system is based on that assumption. That
is to say, the EID->RLOC mapping query is initialized by the ITR, but not
host. Provided that host could be changed and could do the EID-RLOC mapping
query on behalf of ITR and carry the obtained RLOC information in the
packets, most of the pain discussed recently in RRG mail-list will not
exist. 

If the above assumption (host should not be change and still use IPv4) is
true, how will LISP, ivip and other similar proposals deal with the address
depletion problem? Should we still use NAT to solve the address depletion
issues?  If so, we would have to tolerate the side-effect of NAT on the new
application design and deployment, especially peer-to-peer applications
which has already accounted for 80% in total internet traffic volume
nowadays. Or should we adopt IPv6 (IPv6 can be adopted as EID in the above
proposals) to solve the address depletion problem? If so, the change of host
is unavoidable and this is conflicted with the basic assumption of the above
proposals. Or should we operate on the Internet multiple times to solve the
many existing problems one by one? If the deadline of the routing
scalability issue is close to that of the address depletion issue, why not
solve them in one solution?

I doubt why the draft-irtf-rrg-design-goals-01 doesn't take the IPv4 address
depletion into account for a new routing and addressing architecture.

Best regards,

Xiaohu XU

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 17 Feb 2008 22:15:24 -0800

> If I understood correctly, LISP, ivip and other similar proposals  
> are mainly based on one assumption: host should not be changed  
> because the cost of host change is believed to be much larger than  
> that of router change. At least, the recent discussion about the  
> tradeoff between initial packet delay/loss and the scalability of  
> the mapping system is based on that assumption. That is to say, the  
> EID->RLOC mapping query is initialized by the ITR, but not host.  
> Provided that host could be changed and could do the EID-RLOC  
> mapping query on behalf of ITR and carry the obtained RLOC  
> information in the packets, most of the pain discussed recently in  
> RRG mail-list will not exist.

The assumption LISP, in particular makes, is that the design will make  
the least amount of changes to host protocol stacks, host  
configuration files, router code and router configuration files. That,  
with the features documented in the lisp-interworking draft, in my  
book is the true and honest definition of "incremental deployability".

The recommendation for a LISP deployment is to place 2 routers (which  
already exist) at a dual-homed customer/edge site with new LISP code.  
Nothing else in the network has to change. Of course there are various  
cases, if you want to to TE-LISP that an ISP can independently decide  
to run LISP in their domain. And if you want to combine LISP  
encapsulation services and NAT services in one box.

> If the above assumption (host should not be change and still use  
> IPv4) is true, how will LISP, ivip and other similar proposals deal  
> with the address depletion problem? Should we still use

Well an EID/RLOC split adds one new namespace to address systems out  
of. That gives you more addresses on the order of the total  
addressable address space of the namespace's address family (IPv4 or  
IPv6). You could iterate to build multiple levels of hierarchy. Just  
like people have done with multi-level NAT.

> NAT to solve the address depletion issues?  If so, we would have to  
> tolerate the side-effect of NAT on the new application design and  
> deployment, especially peer-to-peer applications which has already  
> accounted for 80% in total internet traffic volume nowadays. Or  
> should we adopt IPv6

My motto is "translate before encapsulate". Because the addresses used  
by the transport protocol are global addresses (one of the addresses  
are global or public where your own is private).

So you combine the encapsulation and address translation services in  
the same box.

We have an existence proof that LISP can work with NAT. That is, when  
implemented in two different boxes in serial. We have on our prototype  
todo list to combine both functionalities in one box.

> (IPv6 can be adopted as EID in the above proposals) to solve the  
> address depletion problem? If so, the change of host is unavoidable  
> and this is conflicted with the basic assumption of the above  
> proposals. Or should we operate on the Internet multiple times to  
> solve the many existing problems one by one? If the deadline of the  
> routing scalability issue is close to that of the address depletion  
> issue, why not solve them in one solution?

That is the intention of LISP. To work with any address family. Hence  
the prototype we are testing, every feature we add gets benefit to  
IPv4 as well as IPv6. And soon, we will have mixed EID-RLOCs (v4 EIDs  
with v6 RLOCs or mixed RLOCs and v6 EIDs with v4 RLOCs or mixed RLOCs).

Dino

--
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: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Feb 2008 10:17:49 +0800

> todo list to combine both functionalities in one box.
I have no doubt that LISP can works well with NAT. But NAT have been a
serious obstacle for peer-to-peer application. As the peer-to-peer has
become the dominative traffic model, we should not neglect the side-effect
of NAT and the need for end-to-end argument since the new architecture
should suit the future traffic model and application demands.
> with v6 RLOCs or mixed RLOCs and v6 EIDs with v4 RLOCs or mixed RLOCs).
If you want to deploy v6 EID, which means a change to host, I guess the
EID-RLOC mapping pressure could be lifted from ITR to host during this
transition. In this way, there is no need for the ITR to have cache and
there is no pain of packet loss/delay when cache missing. And there is also
no need for the ITR to hold a whole EID-RLOC mapping database.

Best regards,
Xiaohu XU

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 19 Feb 2008 00:57:41 -0800

> should suit the future traffic model and application demands.

I hope you are not saying that a Loc/ID split solution should solve  
this problem with NATs? There are solution to solve this in NATs. So  
LISP, colocated with a NAT will take advantage of the solution.

> If you want to deploy v6 EID, which means a change to host, I guess  

No, not at all. Hosts support IPv6 today. So there are no further  
changes. You run IPv6 in hosts and routers at a site. The ISPs can run  
IPv4 or IPv6 as they choose.

> EID-RLOC mapping pressure could be lifted from ITR to host during this

What do you mean by lifted?

> no need for the ITR to hold a whole EID-RLOC mapping database.

1) If you put Loc/ID functionality in hosts, then they will have to  
change. Don't want to
    do this because it kills deployability.
2) The packet loss/delay is for the first packet of the first flow  
between two sites. This is
    pretty minor and people have blown this out of porportion.
3) The ITR need not hold the entire mapping database. There is an  
option to do so, but it's not
    required and arguably not needed.

Dino

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 19 Feb 2008 17:50:21 +0800

> LISP, colocated with a NAT will take advantage of the solution.
Some other id/loc split proposals including SIX/ONE, NODE ID and HRA can
kill these two "birds" with one stone.
> > If you want to deploy v6 EID, which means a change to host, ...
Can most of the hosts and internal routers within site network worldwide
already support IPv6 today? If so, there would be a little pain in the
transition from v4 to v6 with the help of LISP, provided we put weather most
of the applications are v6-ready aside. 
>     do this because it kills deployability.
If you don't hurry to deploy LISP with v6 EID within the forthcoming 3-5
years, time should be enough to upgrade the host stack to support that
function if necessary.
>     pretty minor and people have blown this out of porportion.
We need data to tell us the real impact, otherwise, LISP doesn't need to
propagate so many branches ;)
>     required and arguably not needed.
Does Eliot also agree with this opinion? ^_^

Best regards,
Xiaohu Xu

---

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

Short version:

   When comparing map-encap proposals, we should consider their
   ability to help with the IPv4 address depletion problem.  All
   of them should be capable of making a major contribution to
   improving address utilization.

   This is the problem everyone knows about - so if we can
   say this routing scalability solution is also inherently
   a means of alleviating the IPv4 address "shortage", then
   it will be a lot easier to get people excited about it.

   Also, why we need to avoid changing hosts, even if that
   would be cheaper than changing and adding routers etc.

Hi Xiaohu,

You wrote, in part:

> because the cost of host change is believed to be much larger
> than that of router change. 

I think this is true, but there are some other important aspects.
We need the new kind of address space to be adopted by many,
probably most and ideally all "end-users".  "end-user" means
anyone who wants or needs multihoming, traffic engineering,
portability etc. and either can't get it now with BGP-based address
slicing and dicing, or could get it, and so could add one or more
routes to the DFZ routing table.

No-one is in a position to force large numbers of such "end-users"
to adopt the new address space, so we need to ensure at a minimum
that the new space doesn't suck and secondly that it is is
affordable - hopefully cheaper and better than the alternatives.

Pretty much every such "end-user" uses their address space for
servers and desktop machines etc. which need to communicate with a
broad swath of other servers and desktop machines all over the
world.  Initially, all those other machines will not be using the
new address space, and they will be completely unaltered.

So the new address space has to support communications with the
"rest of the world" in a way which works as well as, or is superior
to, the alternatives - today's BGP managed PI or PA space.

The new kind of space is not suitable for use by ISPs - but it will
be highly suitable to end-users who are not selling connectivity to
others.

If the map-encap's address space involves degraded performance, even
a little, except for when hosts at one or both ends have been
upgraded (OS at least, applications far worse - it will never
happen), then most end-users won't want it and the whole idea will sink.

So for such a scheme A, even if the cost of upgrading all hosts was
somehow less than the cost of upgrading routers, implementing some
alternative map-encap scheme B etc. then scheme A will never succeed
because potential early adoptors generally won't adopt it.

> At least, the recent discussion about
> the tradeoff between initial packet delay/loss and the
> scalability of the mapping system is based on that assumption.
> That is to say, the EID->RLOC mapping query is initialized by the
> ITR, but not host. Provided that host could be changed and could
> do the EID-RLOC mapping query on behalf of ITR and carry the
> obtained RLOC information in the packets, most of the pain
> discussed recently in RRG mail-list will not exist.

With Ivip it would be possible to have a caching ITR function built
into the sending host.  However the system doesn't rely on this.  It
would make sense most where there are cost benefits for the person
who runs the hosts.  For instance, a server farm would have a choice
between purchasing a bunch of high-powered ITRs to do all the work
or installing some free software update to the OS of its servers.

Assuming the task per server is not to heavy on CPU or RAM (as it
would be, except perhaps for the busiest servers which send packets
to a very wide range of destinations), putting the ITR function in
the host would be the best approach.

There's nothing about Ivip which makes in-host caching ITRs (ITFH -
ITR Function in Host - not behind NAT) have higher performance,
because the use of external ITRs provides the highest level of
performance anyway.  It is purely a cost-saving alternative which is
attractive where the host OS can be changed without too much trouble.

If you have some map-encap scheme X which has sub-optimal
performance, except when the sending host is upgraded, then this
scheme will be rejected by most end-users.  These end-users need
their networks to work just as well as with ordinary address space
with the great mass of hosts out there, which initially will not
have any scheme-X-friendly upgrades.

> IPv4) is true, how will LISP, ivip and other similar proposals
> deal with the address depletion problem? 

LISP, APT and Ivip can all slice and dice address space down to much
smaller chunks than the 256 IPv4 address chunks which the BGP system
is currently capable of. (This is an administrative matter, but
clearly it is not going to get any finer, since we are trying to
reduce the growth in the DFZ routing table.)

LISP and APT does it in chunks of 1, 2, 4, 8, 16 etc.  Ivip's
micronets can be of any size, 1, 2, 3, 4, 5 etc.  So Ivip is
marginally more suited to the flexible, fine, slicing and dicing of
IPv4 space we will need, assuming we are stuck with IPv4 for a long
time, which I think we are.

> Should we still use NAT to solve the address depletion issues?  

I think this is inevitable - unless someone can figure out a
backwards compatible way of migrating end-users off IPv4 and onto
IPv6 or some other kind of address system.

> If so, we would have to tolerate the side-effect of NAT on the 
> new application design and deployment, especially
> peer-to-peer applications which has already accounted for 80%
> in total internet traffic volume nowadays.

As long as we are using IPv4, I believe we are stuck with NAT - any
widely used application needs to be able to fight its way out of
whatever NAT or nested NATs, it finds itself in.  There is a lot of
potential for standardising how NAT is applied and how it can be
auto-discovered.  http://tools.ietf.org/wg/behave/ RFC 4787 but
there will be plenty of NATs around for a long time which do not
conform to any such standards.	

> Or should we adopt IPv6 (IPv6 can be adopted as EID in
> the above proposals) to solve the address depletion problem? If
> so, the change of host is unavoidable and this is conflicted with
> the basic assumption of the above proposals. Or should we operate
> on the Internet multiple times to solve the many existing
> problems one by one? If the deadline of the routing scalability
> issue is close to that of the address depletion issue, why not 

I think a successful map-encap scheme will buy us a lot of time with
IPv4 by making it much easier to increase address utilisation and
accommodate many more multihomed end-user networks.  The persistence
of IPv4 will be for for better or worse depending on how you view
the inherent merits of the world adopting IPv6.

My guess is that about 200 to 300 million IPv4 addresses are
currently in use.  See:

  http://www.isi.edu/~johnh/PAPERS/Heidemann08a.pdf

and my analysis at the start of:

  http://www.firstpr.com.au/ip/host-density-per-prefix/

If we assume this to be 15% utilization of the 1.7 billion currently
advertised IP addresses, and apply some factors:

  1 - About twice this number of IP addresses could be
      advertised (theoretically 3.7 billion, I think), if push comes
      to shove, which it surely will in the next five to ten years.

  2 - The new map-encap scheme could foster much better address
      usage, by a factor of two to five.  I can imagine 75% of
      IP addresses being used, as their value becomes higher due
      to continuing demand and the physical limit of 3.7 billion.

So I guess that by advertising all the space, and by using a
map-encap scheme, we could get four to ten times the number of
actively used IP addresses.

To what degree NAT could be further applied to support more hosts
(desktop machines, cellphones, Net-connected LCD "picture frames"
etc.), more individual people using the Net etc. I am not sure.  If
NAT could be standardised so applications could fight their way out
of two or more depths of NAT, then each DSL or ADSL modem, or each
cellphone, could have a NATed address.  Then in principle you could
run an entire ISP from a single IP address and countless billions of
hosts could have this form of IPv4 access.

At the end of all this, someone will probably look back and observe
it would have been easier to rip out every computer and router in
2015 and replace them with IPv6-compatible devices.  Likewise
escaping the ruts of MS Windows and qwerty keyboards!

Since large numbers of desktop machines can be handled behind NAT on
a single IPv4 address, in principle this population of machines can
be handled almost indefinitely on a finite subset of the space,
simply by applying NAT to a greater degree.  Current practice is to
give every cable modem or DSL customer a single public IPv4 address
and let the modem NAT as many machines as they like.  Giving them
NATed addresses instead would mean two layers of NAT and (I guess) a
variety of problems for existing applications, so I doubt this would
happen unless all the alternatives were worse.

> I doubt why the draft-irtf-rrg-design-goals-01 doesn't take the
> IPv4 address depletion into account for a new routing and
> addressing architecture.

The IPv4 address shortage is the big problem virtually everyone
knows about.  Few people have heard of the routing scalability
problem - and not everyone who has heard of it believes it really is
a problem requiring the heroics we are contemplating with a
map-encap scheme.

I believe both the RRG Design Goals and RADIR Problem Statements:

  http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01
  http://tools.ietf.org/html/draft-narten-radir-problem-statement-01

should recognise that a map-encap solution to the routing scaling
problem can and should lead to new methods of address management
which will be crucial in alleviating the IPv4 "address shortage".

I wrote about this in July 2007 regarding the RADIR statement:

  http://www.ietf.org/mail-archive/web/ram/current/msg01772.html
  http://www.ietf.org/mail-archive/web/ram/current/msg01773.html

and should have mentioned it regarding the RRG goals:

  http://psg.com/lists/rrg/2007/msg00199.html

 - Robin          http://www.firstpr.com.au/ip/ivip/

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 21 Feb 2008 16:27:26 +0800

>    improving address utilization.
I agree. In fact, those approaches which use IPv4 address as EID will
alleviate the IP shortage problem, while other approaches which introduce a
new host identifier namespace will solve the address depletion problem.
So should this point be added as a desired option in RRG-Design-Goals?
>    it will be a lot easier to get people excited about it.
Agree.
> the host would be the best approach.
It's a good option which will alleviate the pressure of the ITR. Although
the scalability issue seems nothing to do with the end-user, however, the
continual growth of routing table will degrade the routing stability which
will eventually degrade the service experience. Besides, the first adopter
of this host change will jump out of the initial packet loss/delay pain
provided some LISP-like solution was deployed.

On the other hand, the direct pressure on the carrier should be transferred
partially to the end users in a reasonable way. Although IETF/IRTF is not a
suitable place to talk about business model, it should consider offering
some corresponding solution once some business model succeeds.
> conform to any such standards.
IPNL-A NAT-Extended Internet Architecture is a good idea, it not only
overcomes the side-effect of NAT which destroy the e2e argument, but also
utilizes the NAT box to extend the address space (global IPv4 address+
private address=a new and bigger address space). There is no need to upgrade
all the routers except the NAT boxes. Of course, the host should be changed
to use FQDN as host identifier.

Best regards,
Xiaohu XU