Market-based address allocation

> As a thought experiment, think of how the IPv4 addressing situation
> (bogon advertisements, allocations, explosion of routing table sizes,
> etc) would be different if the IP community treated IP addresses as a
> commodity.

PIARA, The Sequel. Take N+1. Action! Anybody got any rubber balls
Peter Lothberg can monopolize this time? :slight_smile:

  I still have mine, plus the five or six I took away from
  the others in the room. ... psst, buddy, want to buy an
  "8"

Sorry to be flip. In case you haven't already, see:
Orbit ‚Äď APNIC

  Oh... sorry, are folks really seriously wanting
  to treat integers as a marketable commodity?

Well.. they're already considered leasable/rentable. <ducks> :wink:

(Yes, I know - what you're REALLY paying the registry for is to keep
records of who has what. On the other hand, the concept of a certificate
conveying the right-to-use an integer or range of same isn't THAT more
disjoint from reality than the concept of a stock market where you trade
shares in a company, in the hope that you can sell it for a profit later.

  Oh... sorry, are folks really seriously wanting
  to treat integers as a marketable commodity?

  Any work that can be produced in digital form has a corresponding integer.
Every Disney movie does.

  DS

On Wed, Apr 30, 2003 at 02:24:33PM -0700, David Schwartz quacked:

> Oh... sorry, are folks really seriously wanting
> to treat integers as a marketable commodity?

  Any work that can be produced in digital form has a corresponding integer.
Every Disney movie does.

1-800-COLLECT is probably the most pertinent example.

www.business.com is a close second.

The license plate "UNIX"

The source code to Windows

  -Dave

Treating IP space as a commodity is no more strange than trading financial
options or other derivatives, or, for that matter, intellectual property.
Bits, numbers, and agreements all hold value outside of the context of
purely physical property.

Sadly, this sort of idea tends to stomp on the socialistic sort of
idealism that is particularly prevalent amongst some in the IETF and NANOG
communities, who feel it would leave out the "little guys". I suspect that
any real world float of IP address space would result in a pretty low
price per ip address, if the market was sufficiently liquid. It might be
cheaper for a little guy to get a few $K together for IPs, then to build a
network capable of "justifying" a /20 from an RIR.

Maybe ARIN should reinvent itself as a mercantile exchange?

- Dan

> Oh... sorry, are folks really seriously wanting
> to treat integers as a marketable commodity?

Treating IP space as a commodity is no more strange than trading financial
options or other derivatives, or, for that matter, intellectual property.
Bits, numbers, and agreements all hold value outside of the context of
purely physical property.

In this context, which is more real:

  1) That highly dense, "gold"-colored bar of metal
  2) The little green pieces of paper in my wallet
  3) The ones-and-zero's that make up the balance in my checking account

IMHO, these are ordered correctly from a physical standpoint but ordered
backwards in terms of marketablility... If you have $100's worth of gold,
a one hundred-dollar bill, and $100 in your checking/debit account - which
is the easiest to transact with?

Eric :slight_smile:

In this context, which is more real:

  1) That highly dense, "gold"-colored bar of metal
  2) The little green pieces of paper in my wallet
  3) The ones-and-zero's that make up the balance in my checking account

Ok, well, maybe not the ones-and-zero's in __MY__ checking acount (which
are really all zero's) but you get the point...

Eric :slight_smile:

Daniel,

So, lets say we go ahead a float IP address space and anyone can buy whatever prefix they think need and have the cash for.

What happens to the routing tables?

The reason the BOF back in '96 was entitled "Pricing of Internet Addresses and Routing Announcements' was that the folks who seriously considered the idea realized that in the IPv4 CIDR world we live in, selling address space without somehow tying those sales into some sort of market for routing prefixes was a recipe for "fun", or at least lots of prefix length filters and subsequently more unhappiness.

If someone can figure out how to get the ISPs of the world to participate in a routing prefix market, then it might be worth revisiting this idea. Note that there is nothing stopping establishing a routing prefix market now, so it could be done prior to changing address allocation policies.

Rgds,
-drc

These two things have to happen at the same time:

  1. ISPs start charging for the service of advertising each
      prefix upstream and/or to peers.

  2. Customers can purchase netblocks on an open market.

With both #1 and #2, customers can decide (based on financial incentives) whether to

   (a) pay for the service of advertising lots of small netblocks,

   (b) buy "big-enough" netblocks and renumber into them to save
       on per-advertisement service fees, or

   (c) use provider-based addressing and bear the risk/costs of
       renumbering when changing providers.

Without #1 above, there's no financial incentive for customers to renumber into better aggregated netblocks. As I understand Randy's argument, this is a flaw in the Internet economic model, because the costs are borne by the service providers but the benefits accrue to other networks' customers.

Without #2 above, it's much harder to put a dollar value on the cost of (b): the price is difficult to determine in advance due to the utilization review uncertainties.

Using my institution (AS 683) as an example, we advertise about seven /16s and a pre-CIDR block of swamp /24s. As much as I would like to aggregate everything into a larger netblock, there are some obstacles that I can't overcome by "community pressure" or "doing the right thing."

I wish I could put dollar figures on the asset valuation of the various netblocks, the capital cost of larger netblocks, and the recurring cost to my institution of making 14 advertisements. Today I can't do that.

Sorry, just remind me.. what exactly is the point of any of this anyway?

Surely the Internet exists to serve webpages and deliver emails and other than
those techies on this list no one cares how big your prefixes are or how many
you have, providing you serve their office needs.. ?

Steve

I guess the better question is, what changed between 1996 and 2003?

- Processor speeds have increased dramatically
- Memory is dirt cheap in a way almost unthinkable in 1996.

So, a little additional routing table bloat hurts no one. Yes, yes, this
is heresy.

Of course, that doesn't mean that a market based system causes ANY additional routing
table growth...

- Carriers have no incentive to change their filters

- The current length filters work quite nicely. /20s are always routable,
/24s are usually routable, depending on the weather, etc. YMMV, of course.

- ARIN, or whomever is the brokerage/dealmaker/clearinghouse for these
deals can simply refuse to transfer anything smaller than a /20, unless
its in legacy swamp space

- The sellers would, for their own protection, refuse to stipulate that
ANY block they sell is globally routable, if they have any sense.

- Of course, current, more or less unutilized class As and such might get
sold off in /20 chunks and advertised, but theres nothing wrong with this.

If, by a routing prefix market, you mean that folks with lots of prefixes
get to pay folks to carry their data, then its a DOA idea. Current
Settlement Free Peering arrangements work fine - no one is looking to
upset the apple cart.

- Daniel Golding

- Processor speeds have increased dramatically
- Memory is dirt cheap in a way almost unthinkable in 1996. [but see smd's p.s.]

Incredible scale in one fewer dimension is *good*.

Divide and conquer, within router systems, has been
enormously successful. Moreover, putting relatively
less work onto the general computing part of a modern
large router has given us one less thing to worry about
compared to the general computing industry. Given
the amount of work it takes to build IP-forwarding hardware
and nowadays specialized RAMs, this is a good thing.

The amount of memory in large router systems has
increased substantially, but not as substantially as
the pps switching power of the same platforms.

Rough numbers, not taking into account buffering,
code bloat, architectural issues, bank holiday laziness,
the hangover from faak.subnet.dk, and so on -

1996: 8-slot x ~50 Mbps, ~256 MBytes RAM per system
...
2003: 16-slot x 40-Gbps, ~16 GBytes RAM per system

Fewer doublings.

Bandwidth scaling, system: 500 Mbps vs. 500 Gbps -> 3 orders of magnitude, base ten (10 in base 2)
Memory scaling, system: 320 MBytes vs 16 GBytes -> 2 orders (base 10) (6 in base 2)

System memory has scaled less than typical city-to-city core bandwidth builds:
1996: ~OC3 x 1
2003: ~OC192 x 8 (aka OC3 x 512 - 9 orders of magnitude, base two)
           Yes, this *does* require interesting POP geometry, but so did ~155 without POS.

Memory has also needed to become much faster, of course,
to handle the arrival, storage, manipulation, and departure of the all bits
through various parts of a system (often with an internal speedup
over the max slot/interface bandwidths).

In-system memory these days is used more by specialized pps
hardware, not by general-purpose CPUs. Most development
work has therefore gone into these chips
to allow for more operations-per-packet (mmm, pipelining) and
more packets per second, while the expectation is that
cooler, stabler general purpose CPUs and ordinary RAMs
will suffice for constructing the data structures these forwarding
engines operate upon.

More importantly than keeping the "routing brain" underpowered
compared to run-of-the-mill PeeCees, constraining the amount
of state in the network gives us some system slack in making
time-space tradeoffs within a routing system (and parts thereof).
As an industry, we can cope with memory speed increases
levelling off, OR with specialized chip production slowing down.
Increasing the amount of state in the network destroys
a very important belts-and-braces approach to growth.

So, a little additional routing table bloat hurts no one. Yes, yes, this
is heresy.

If all systems scaled in proportion to the "routing brain" ONLY,
with the "routing brain" needing to be essentially just a PeeCee
or Mac, you would be right.

Unfortunately, this is not the case in the core, and the core
is an expensive contribution to your monthly bills. However,
it's nowhere near as large a contribution as what you likely
are paying your "recovering monopolist" local access provider.

Core costs get constrained because, as an industry, they must.
If you stop the LAP being more than 50% of the price of connecting
to the Internet, then yep, we can afford to be much more lax
with respect to the routing table, even if it results in much more
expensive core routing devices.

- Carriers have no incentive to change their filters

Except the bloody noses one gets in the press from time to time.

- The current length filters work quite nicely.

Thanks. I think so too, still.

If, by a routing prefix market, you mean that folks with lots of prefixes
get to pay folks to carry their data, then its a DOA idea. Current
Settlement Free Peering arrangements work fine - no one is looking to
upset the apple cart.

Except at least ITU-T study group 3 (google on SG3 D.50 and *be concerned*).

I personally would like a time-machine to go back and implement a web form
that would allow one to use a credit card to blow holes in the prefix-length
filter for a reasonable monthly fee, as opposed to effectively $INFINITY,
and open-source the software.

Note for motivated coders: it's not too late for this... As drc wrote:

If someone can figure out how to get the ISPs of the world to
participate in a routing prefix market, then it might be worth
revisiting this idea. Note that there is nothing stopping establishing
a routing prefix market now, so it could be done prior to changing
address allocation policies

There are certainly other approaches than this, but
I believe this would have solved most of the problems in CIDRs childhood,
and eliminated quite a few we are starting to see as it approaches puberty.

  Sean.

P.S.: I guess I have a different view of "unthinkable price reductions".
         Do you pine for 1990's $6/hour 9600bps dialup IP too?

         In mid 1997 the price per Mbps per month ("non-overbooked") in
         Europe was about USD 17000. Pricing is now in many cases
         around USD 170. (I don't take into account inflation and exchange rate...)
         Trans-Atlantic *traffic* has gone from about a Gbps to perhaps a hundred.
         The Internet industry's ability to deal with the market with only a few mostly
         parent-company-inflicted organizational collapses is pretty astonishing.

         This, however, does not mean we should make it HARDER over the next
         few years. The "boring lull" some tech-focused people have complained
         about is a cyclical thing (T1 -> nxT1; T3 -> nxT3; OC3-nxOC12;
         OC48-nxOC192 periods for example), and is probably approaching its end.
         Remember the fun of SSPs, CIDR collapse, POS, gated vs "everyone else's" BGP,
         FIB switching, BFR/GSR, JunOS, packet over WDM? Step changes take
         a bit of advance planning and development; shifting the target in the wrong
         direction just before one is publically unleashed is, well, something I'd rather
         you not do.

What *didn't*?

Oh wait. I know. I know. "IPv6".

  Sean.

Very good point--the issue is one of the amount of core state, whether that state is created through unicast BGP prefix advertisements or multicast MSDP Source Active advertisements.

In each of these cases, I believe service providers should charge the customer for state that is (or could be) created in the core.

Today, service provider costs are generally driven by a combination of

    circuit costs (read: recovering monopolist telcos)
    equipment costs (packets-per-second)
    equipment costs (amount of state the equipment can handle)
    real-estate costs (roughly proportionate to number of customers,
                       and includes things like power and cooling)
    people costs (proportionate to quantity of customers and equipment)

Pricing to the customers, however, is generally driven by the customer's requirements for bandwidth, not the customer's ability or desire to create state within the core. This leads to the following pernicious distortions (two of which come off the top of my head; there may be more):

  - Service provider sales/marketing has a perverse anti-incentive to
    promote multicast. If multicast is promoted, then the immediate
    result is a *reduction* in their commissions, because multicast
    service reduces the customer's demand for billable bandwidth
    utilization.

  - Customers end up charged for provider-specific IP addresses. The
    costs to the service provider for managing and allocating IP
    addresses need to be covered, of course. But if the *customer*
    covers those costs, then the customer has an incentive to acquire
    portable address space--which is then independently routed,
    increasing the amount of state in the core.

As a customer of the voice telephone industry, I have the option of accepting a provider-assigned telephone number when I establish service. Or, I can pay a little more and retain my previously-assigned telephone number. The choice I make depends on how much the telephone number change will cost me overall, taking into account the cost of preserving the prior address versus the costs of communicating my new telephone number to actual and potential callers.

In the IP world, the cost of advertising the new IP address to actual and potential communicators is relatively low due to DNS. But the cost of being able to *accept* those communications may be much higher, since I have to change state in all the devices (servers, routers, etc) that expect to receive messages using the old addresses.

This ignores commercial reality. Its fine to ruminate on how we may want
things to be, but in the real world. no one will ever charge for route
announcements, any more than people charge "installation fees". They will
be immediately waived.

Some folks do charge for IP space, but this leads to significant problems,
as it makes it very hard to issue space based on justifiable need - "I'm
will to pay for an extra /20, so why can't I have it". The reason, of
course, is that when the provider goes back to ARIN for more space, the
fact that someone was willing to pay isn't considered proper
justification...

Also, there are problems with folks who pay for address space believing
that they somehow own it.

You have given an excellent reason, why, as an industry, we are not
interested in promoting multicast. Of course, the other reasons are its
nasty degree of complexity when troubleshooting and occassionally buggy
implementations. That, and customers never ask for it.

Demand drives implementation. Demand drives billing methodology. Not
always happy news for the techie, but there it is.

- Daniel Golding