John Olp wrote:
Sorry for getting in late on this but...
The argument that multicast should be billed based on the number of receivers is flawed. Those receivers are already being billed based on the bandwidth they use regardless of source.
They are billed by their ISP for the traffic they receive. This doesn't cover the cost of sending the data to them on the sourcing ISP. This is why you pay for both traffic you send and for traffic you receive. Both cost your provider money to do for you.
In other words, the multicast source is not, as someone suggested, using more backbone that it is paying for. Everyone receiving a multicast feed is also picking up the cost of their respective traffic.
Let's take an example. I'm a small provider. I have an OC3 to FooNet and an OC3 to BarNet and I get full transit on both. I sell a DS3 to someone. Using unicast, they can consume at most 45Mbps out of my total of 2 OC3s of outbound bandwidth (which I pay for). They can consume at most 45Mbps out of my total of 2 OC3s of inbound bandwidth (which I pay for). Now I set them up with a multicast feed. They can now use up to 90Mbps of my outbound bandwidth (which I pay for). How can I charge them the same amount when it can cost me up to twice as much? Now you can argue that I should just eat this cost. That's not entirely unreasonable. After all, some customers may use more transit than peering, and generally they pay the same amount. But the net effect of this is that I have to raise my overall prices. If I have the same billable bandwidth but I'm billed for more, I have to charge more. Otherwise, the more multicast I deploy, the less money I make. In any event, it has always been my position that where possible and within reason, ISPs will be most competitive (and the Internet will remain the most stable) if they can develop and implement pricing models that charge their customers based upon the actual cost to provide the customer with the service. DS