Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Multicast Traffic on Backbones

  • From: Steve Schaefer
  • Date: Fri Jun 15 11:42:57 2001

On Thu, 14 Jun 2001, David Schwartz wrote:

> 	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).

Well, I initially found this argument persuasive.  So I did a little
modeling.  (Just back-of-the-envelope work.)  I am now convinced that
multicast is a good deal for almost everyone.

1) National Backbone - Unless the multicast group is trivially small, the
revenue for the national backbone provider will be at the receiving end.
The revenue is essentially unchanged.  The costs are at the receiver's
access link (unchanged) and in the backbone transport (significantly
reduced).  Good deal.

2) Small ISP's - These organizations are unlikely to host significant
outbound multicast traffic.  If they do have an instance of this, it is
only rarely going to matter, since small ISP's are typically paying for
equal capacity of inbound and outbound transit, and have outbound transit
to spare.  Anytime a small ISP has two multicast receivers in the network,
they get to use their (expensive) inbound transit once, and bill for
access twice.  Good deal.

3) Regional ISP's - Well, for inbound multicast, see above.  For outbound
multicast a Regional ISP will have reduced backbone costs for
distribution, but they will also have increased transit costs, since they
almost certainly are paying for multiple transit paths.  This case looks
the most like the case above.  If this is an ISP with a balanced access
and hosting business, then hosting the multicast service will almost
certainly result in some additional access revenue.  Also, the regional
ISP is probably limited by inbound capacity (but not always).  Probably a
good deal.

4) Unicast hosting provider - Now for these guys it's different.  Backbone
costs are minimal on outbound traffic because it gets dumped off at the
nearest interconnection point.  They are not likely to pick up access
circuit revenue as a result of hosting the multicast, since they might not
even have access circuits in their product line.  They probably pay for
some transit, and the capacity is limited by the outbound load.  So
originating multicast traffic means that the hosting company bills once
and pays out every transit.  Bad deal.

In the long term, I'm not so sure it's even a bad deal for the hosting
providers.  Looking at the revenue streams in a multicast environment, the
money is at the receiving end.  That means that content actually is king,
and these guys might get much better treatment in peering negotiations as
multicast takes off.

> 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?

Hmm.  I think the point is shallow.  For example, should your transit
providers charge double, too?  After all, you could have to traverse
their backbone east-to-west and north-to-south, but you only paid once!

There might be a slight shift in some business models, since the revenue
moves more to the receiving end.  If you're a small ISP and you are
actually limited by outbound transit, then either turn the business away
or invest in the future, believing that content on your network is
important and you'll pick up more access revenue.  If you turn it down,
someone else will want the business.

Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.