Multicast Traffic on Backbones

Fri Jun 15 06:38:31 UTC 2001

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