Internet core scale and market-based address allocation
dgold at FDFNet.Net
Mon May 5 20:16:03 UTC 2003
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
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
On Mon, 5 May 2003, Bill Nickless wrote:
> At 05:18 PM 5/5/2003 +0100, Sean M.Doran wrote:
> >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.
> 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
> - 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.
> Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390
> PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless at mcs.anl.gov
More information about the NANOG