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 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 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.
=== 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@mcs.anl.gov