(almost) any verio customer can receive multicast. It is available upon request. Let me know if you are a verio customer and require assistance getting multicast. - Jared On Sat, Jun 09, 2001 at 07:09:01PM -0700, Joel Jaeggli wrote:

verio and l3 are both multicast enabled... I don't know the extent to which it's available as a customer...

joelja

On Sat, 9 Jun 2001, Deepak Jain wrote:

...

Don't know why I came across this, but I found a document on Sprintlink's site that says their entire backbone is multicast enabled, and they also peer with the MBONE for multicast traffic. They charge no fee for dedicated customers to be multicast-enabled.

Are any other major networks doing this? Or have I been living under a rock and _everyone_ is doing this now?

Thanks,

Deepak Jain AiNET

-- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

The advantage is that you can turn up a customer the same day compared to having to schedule some maintence to make the network multicast enabled. Making all your bgp sessions do unicast+multicast is a trivial configuration change and does not cause any extra instability. Then you can turn on/off pim to the edge where the customer is attached as needed. - Jared On Sat, Jun 09, 2001 at 10:43:54PM -0400, Deepak Jain wrote:

I think I should have been more clear.

When multicast enabling a network, am I wrong in assuming that the routers will only multicast to their direct, end-user connections and peers (like an access router will only offer streams to its direct connections)? I am trying to figure out what advantages multicast-enabling a backbone has when the majority of customers are not multicast-peers of their upstream routers.

Thanks,

Deepak Jain

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Jared Mauch Sent: Saturday, June 09, 2001 10:33 PM To: Joel Jaeggli Cc: Deepak Jain; Nanog@Merit. Edu Subject: Re: Multicast Traffic on Backbones

(almost) any verio customer can receive multicast. It is available upon request. Let me know if you are a verio customer and require assistance getting multicast.

- Jared

On Sat, Jun 09, 2001 at 07:09:01PM -0700, Joel Jaeggli wrote:

...

verio and l3 are both multicast enabled... I don't know the extent to which it's available as a customer...

joelja

On Sat, 9 Jun 2001, Deepak Jain wrote:

...

Don't know why I came across this, but I found a document on

Sprintlink's

...

...

site that says their entire backbone is multicast enabled, and they also peer with the MBONE for multicast traffic. They charge no fee for dedicated customers to be multicast-enabled.

Are any other major networks doing this? Or have I been living under a rock and _everyone_ is doing this now?

Thanks,

Deepak Jain AiNET

-- -------------------------------------------------------------------------- Joel Jaeggli joelja@darkwing.uoregon.edu Academic User Services consult@gladstone.uoregon.edu PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -------------------------------------------------------------------------- It is clear that the arm of criticism cannot replace the criticism of arms. Karl Marx -- Introduction to the critique of Hegel's Philosophy of the right, 1843.

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

-- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

Christopher Johnston wrote:

Intermedia Business Internet has been running multicast enabled for a couple of years now. It is an unsupported service that is freely available to all dedicated customers.

Glad to hear this ! Just for the record, you can see the full current list of participants in the multicast enabled Internet at http://www.multicasttech.com/status/mbgp.sum This is updated dynamically serveral times per day. Regards Marshall Eubanks

...

On Sat, 9 Jun 2001, Deepak Jain wrote:

Don't know why I came across this, but I found a document on Sprintlink's site that says their entire backbone is multicast enabled, and they also peer with the MBONE for multicast traffic. They charge no fee for dedicated customers to be multicast-enabled.

Are any other major networks doing this? Or have I been living under a rock and _everyone_ is doing this now?

Thanks,

Deepak Jain AiNET

---- Christopher Johnston - cjohnston@intermedia.com Manager, Tier III & Network Operations Intermedia Business Internet 24-hour Support 888-297-1400

T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme@multicasttech.com http://www.on-the-i.com Test your network for multicast : http://www.multicasttech.com/mt/ Check the status of multicast in real time : http://www.multicasttech.com/status/index.html

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

John Olp wrote:

...

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.

Precisely the thoughts I intended to provoke.

Assuming the group members are other customers of foo and/or bar, then foo and/or bar are charging both you and those customers (essentially charging you for something already paid for). Even if foo/bar is just routing to some other network and just passing on their overcharge to you, the argument stands that someone is charging twice for the same traffic.

No, they are not being charged for the same thing. The originator is being charged for the originating network's costs of getting his traffic off the originating network towards the recipient. The recipient is charged for the recipient network's costs of getting his traffic from the originating network and to the recipient. In the simplest case, where your ISP and my ISP meet directly at a peering point and you send me a packets, the costs go like this: You pay for your line and your ISP's costs of keeping that line operational. You pay the cost of getting traffic from your line to wherever the router is that peers with my ISP. You pay part of your ISP's costs in maintaining that peering link. I pay for my line and my ISP's costs of keeping that line operational. I pay for some of my ISP's costs in keeping that link to you operational.

While it might be true that you have a cost based on your transit/peering agreements (i.e. the pricing model), the argument stands that multicast doesn't cost more. The truth is, it costs less. You're just being charged more because you accept it. And to recoup your cost, you consider passing it on to your customer (who with this model concludes multicast isn't cost effective).

But it does cost you more. You are ignoring the example of mine wherein it clearly costs you more.

I haven't begun to conceive a model that works to everyone's satisfaction, but it's plainly obvious the existing model doesn't work in favor of multicasting. You can bet that whoever is pocketing the overcharges is not going to stop on their own accord. But until we come up with the right model, the profit potential of unicast is going to remain an obstacle to the general acceptance of multicast.

You now have two self-contradictory arguments. One argument is that people are profiteering from multicast. The other is that they make more money with unicast. You can't have it both ways. If ISPs can get rich off of multicast, then they will promote it. Eventually, competition for multicast will bring the prices more in line with the actual cost to provide the service. While I agree that multicast is caught in a catch-22, it's not the one you think, it has nothing to do with cost. It just has to do with the fact that nobody wants multicast until enough other people have it. There are a few ways out of this (killer app, gradually increasing penetration, early-adopter incentives, and so on) but none of them have much to do with pricing. DS

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.

David Schwartz wrote:

...

John Olp wrote:

...

...

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.

Nice bit of double-billing.

One packet traverses the network, and two people pay for it.

-- David

You mean one packet traverses *TWO* networks, don't you? DS

"David Schwartz" <davids@webmaster.com> wrote

...

You mean one packet traverses *TWO* networks, don't you?

probably - but you will still charge on this scheme if both sender and recipient are your customers, won't you?

Some people do, some people don't. It depends. The company I work for does not charge for traffic within a POP. If you expect this to be a large fraction of your traffic, you should definitely negotiate a contract where you don't have to pay more for this. If you expect this to be the usual percentage of your traffic, then you should just understand that it's figured into the price. If you pay, say, $200 per megabit per second per month for traffic over your DS3, this price is based upon the average your ISP expects your traffic to cost it. Some traffic will be very cheap, perhaps going to a machine in the same POP as your DS3 terminates. Some will be very expensive, requiring them to haul it far over their backbone or pay high rates to get it to/from someone else. When your ISP sets the rates you pay for your traffic, it's (at least usually) based upon their expected costs for providing that traffic. If your usage breaks that model, either generally being more expensive (as multicast can be) or generally being cheaper (say all your company's offices use the same ISP with lots of VPN traffic) then you or your ISP should negotiate for a different price or pricing model. If an ISP insisted on charging you much less than your traffic actually costs it, it would go out of business. If an ISP insisted on charging you much more, you would go elsewhere. An important point is that there is absolutely no meaningful difference between the following statements: 1) Both the sender and the recipient pay for the traffic, thus being double billed. 2) Both the sender and the recipient contribute to the cost of the traffic between them. 3) The sender pays to bring the traffic from him to some point and the recipient pays to bring the traffic from that point to him. The simplest way to put it is that passing a packet from an origin to a destination creates costs from the beginning to the end of that path. The agreements covering the various links that packet flows over work out how thoses costs will be borne. The parties at both ends of the link must find the agreement covering the exchange of that traffic divides the costs reasonably fairly or the link wouldn't exist. DS

On Sat, 9 Jun 2001, Tim Winders wrote:

UUnet has two levels of multicast capabilities. Their "Basic" package is receive only and is free. Their "Gold" package is full send/receive, but they charge a ton for it. The basic package seems pretty useless to me. To join a multicast group, you have to be able to send to it, right?

not right. with many/most multicast protocols, you can (sometimes must) build a source-rooted tree, not a shared tree. joining as a receiver is then a matter of becoming another branch off the tree, hopefully along the reverse shortest path to the sender. in this case, you can send but not receive. possibly the difference is in your permissions to establish a (s,g) pair or to announce a core (RP). which multicast routing protocols are on offer? PIM-SM? MSDP? MBGP? if you can't get your multicast across the border, it may not be useful to you. there are better protocols in the literature than are deployed but the arcana is often politically anathema for inertial, commercial or plain lack-of-working-code reasons.

I have found that most sales reps don't know what multicast is, or why it is important to have.

many network engineers glaze over at the mention of multicast. it takes some serious grey matter work to fathom the entire subject.

On Sun, 10 Jun 2001, Tim Winders wrote:

Now my eye's are glazing over. :-) Did you mean "receive but not send"

i did indeed. there wash shushi in my keyboardsh.

UUnet's arguement for charging to sendis that you can potentially chew up large portions of their network bandwith with only a small connection yourself.

what else is multicast for? hopefully it works out cheaper than your expected outbound unicast streams would have cost (including the clue overhead for supporting mcast)

Very true. I am having a hard time grasping the technical specifics. It has taken quite a bit of study and discussion to figure out what I have so far, and I am sure I have misunderstood many things. Unfortunately, what I am finding out, is that multicast is a subject that rarely comes up as an option with customers. There isn't a demand, so the providers don't put the resources into it...

things don't gain momentum if they keep changing direction. <sotto-voce>the same might be said to the v6 folks</sotto-voce> - J

On Sun, 10 Jun 2001, Tim Winders wrote:

However, with unicast, if you have a 10MB connection, you can't send more than 10MB with unicast. If you need more bandwidth, you buy more.

My argument back, was that it is highly unlikely that I will have 100 different receivers which will have 100 different paths across their network. If their network is designed properly, there should be less impact on their network with multicast than with unicast. I hope they buy that. :-)

Now you get to a Randy Bush argument of what are you actually paying me for (Sorry Randy, but I like your comment so I decided to apply it here) from the provider. If the provider is assumming all the risk for your flow should they not be compensated for the flow? If you are going to have N times receivers of your stream, should they then not have the ability to charge you some factor greater than 1 to support the flow? One method is to limit the amount of bandwidth of multicast per edge interface, but if a 128K stream is sent to hundreds or thousands of places then it could impact certain links as well. Maybe not the backbone running at OC-x speeds... The impact to their backbone is calculated on a fixed connection speed. There have been enough studies that proper traffic engineering can be accomplished with Y number of connections at X data rate. The larger number Y is the actually closer that they can better construct their models. Then with actual trending they can forcast and the situation continues.... Then comes multicasting... If I started streaming a popular live event (since so much attemtion with multicast is for multimedia anyway) at say 384K and tens of thousands of people subscribe there will be N number of nodes that will be getting the stream once, but the overall impact to the network on any given link is 384K, but the overall impact would be N times of 384K. That could amount to a total aggregate of say 10times that you are paying or higher. I would think that a charge based on number of receivers at a reduced rate over unicast would be in order.

...

...

an option with customers. There isn't a demand, so the providers don't put the resources into it...

That is the way our economy works...

On Sun, 10 Jun 2001, Eric Gauthier wrote:

...

they not be compensated for the flow? If you are going to have N times receivers of your stream, should they then not have the ability to charge you some factor greater than 1 to support the flow? One method is to limit the amount of bandwidth of multicast per edge interface, but if a 128K stream is sent to hundreds or thousands of places then it could impact certain links as well. Maybe not the backbone running at OC-x speeds...

I'm relatively new to multicasting, but my impression is that if you have a 128K stream that you are sending out then, even if you are sending it towards hundreds or thousands of places, no individual link would have more than 128K on it (thus the point of multicasting). There may be hundreds of different links each with an additional 128K, but the N-factor amplification you are referencing would be more from the "we now have to send this same 128K out 20 different peering links and possibly (depending on your peering policy) pay 20 times the bandwidth cost" but it shouldn't cause any individual link to become overloaded.

In the original message keep reading. I stated the same thing. The concept is not just to a peering location, but say you have hundreds to thousands of receivers, each link is getting (in my example 384K) then you have N number of links each getting 384K. If you have a backbone with say 500 major links and there is a receiver off each wanting this traffic, then the backbone provider is duplicating your traffic 500 times, delivering it to 500 locations, but being paid for one 384K flow. Another manner to look at this is that in tradiational uni-cast there is a hop on and a hop off that is a 1 to 1 relationship. In multicast there is a 1 to N relationship and the provider is still being compensated on a 1 to 1 basis. The coutner to this is that each party is paying a hop on and hop off so why should the provider be compensated more as each end party is paying for their connection. The myth to the latter argument is that you are not truely paying for the cost of delivering the packets from A to Z, the providers count on the ability to aggregate traffic and knowing that at any given moment that their tail links are not consumed. It is risk management, traffic engineering, whatever you want to call it, but it ammounts to knowing that there is not a full 1 to 1 relationship. Multicast if it ever becomes widely deployed will shoot the theory and pricing model and one of two things will happen in my opinion: Cost for multicast traffic will skyrocket as providers of content reduce their demands for bandwidth (take 1000 streams of 384 and I can get it on a T1 vs multiple OC-3), or cost for all connections will increase.

Now you get to a Randy Bush argument of what are you actually paying me for

credit where due department: i was merely channeling a position sean doran has taken for many years and, while we have a non-op message o after five years, i graduated from verio a couple of months ago, and am now at at&t doing research and architecture o i suspect the nanog thread regarding which backbones have native multicast enabled may be inaccurate. but it's good to see new folk exploring the technology o the folk most interested in revising the meaning of "tier-1" are usually those who are not o the kiddies are out for the summer nothing constructive to do, so are impersonating net operators on aim, phone, etc. so verify cold calls, aim, etc. o ipv6, mpls, and diffserve-enabled backbones will solve all your problems randy

o ipv6, mpls, and diffserve-enabled backbones will solve all your problems

Think you missed making sure you cook this lot up on top of ATM SVCs and season with tier-1 peering to taste before diffserving. Alex Bligh Personal Capacity.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

o i suspect the nanog thread regarding which backbones have native multicast enabled may be inaccurate. but it's good to see new folk exploring the technology

Well, since I am participating in that thread, I would love to hear what information is correct and what is incorrect (inaccurate). At this point in my research, I can only go on what I have been told by sales dweebs and the engineers they manage to conference call into the conversation... === Tim ********************************************** Tim Winders, MCSE, CNE, CCNA Associate Dean of Information Technology South Plains College Levelland, TX 79336 Phone: 806-894-9611 x 2369 FAX: 806-894-1549 Email: TWinders@SPC.cc.tx.us ********************************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OSF1) Comment: Made with pgp4pine 1.76 iEYEARECAAYFAjskHr0ACgkQTPuHnIooYbyHaACeNSB0DPteswoSuYi0zHI9LPSB Yz0AnjeYnm3X43omwx7cbiYYuW3rOWat =24Fb -----END PGP SIGNATURE-----

On Sun, Jun 10, 2001 at 09:44:53PM -0700, Austin Schutz wrote:

...

o the folk most interested in revising the meaning of "tier-1" are usually those who are not

And the folks most interested in retaining the "current" definition are usually those incumbents who coined it and obtain the most benefit from the layer 8+ part of their definition.

Austin

As someone who didn't know history, I see I am doomed to repeat it. I see in the nanog archives the same topic discussed some months before I joined the list. Apologies to all for rehashing hash. Having said that, rfc2519 (published 2/1999) makes use of the term, '"Tier 1"', without any implication as to whether or not the term implied compensation for "transit". My point is not "I'm right", merely that the term has effectively made its way from being merely marketspeak to common technical usage, and that there may not be a common single technical definition for the term. Personally I think the network between my workstation and the local quake server is tier 1, everything else falls somewhere below. Austin

On Sun, 10 Jun 2001, Joshua Goodall wrote:

many network engineers glaze over at the mention of multicast. it takes some serious grey matter work to fathom the entire subject.

I do not know that I would agree on that aspect, but if they did then it would be the result that multicast works in reverse of unicast. If the same person were to learn multicast then they just might learn better the fundamentals of unicast as well.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 10 Jun 2001, Michael Whisenant wrote:

On Sat, 9 Jun 2001, Tim Winders wrote:

...

AT&T has most/all of their backbone natively multicast enabled and will multicast enable customer access routers upon request. They do have a setup fee, but no monthly recurring fees.

Fundamentally is that not the way that it should be?

Yes, I agree.

I think that if I were an AT&T customer I am paying for the ability to flow bits at whatever speed my link or service contract was permitted. It should not depend if those bits are multicast bits or unicast bits. Then in my selection of a provider the provider that offered me more features for the same dollar would have a larger value and ultimately win my decision process.

Again, I agree. I am struggling with this issue right now.

...

UUnet has two levels of multicast capabilities. Their "Basic" package is receive only and is free. Their "Gold" package is full send/receive, but they charge a ton for it. The basic package seems pretty useless to me. To join a multicast group, you have to be able to send to it, right?

If you are wanting to receive multicast traffic of a live event for example, no you would not have to send to the multicast group. Your client would send an IGMP join request to the (*,Group) and then ultimately receive (host, Group) of data. Your clients and routes only need to know that there is a host registered to receive the data, then they will not PRUNE the flow.

Thanks, Michael. I had one other person inform me that JOIN requests are done with IGMP. I appreciate the correction. === Tim ********************************************** Tim Winders, MCSE, CNE, CCNA Associate Dean of Information Technology South Plains College Levelland, TX 79336 Phone: 806-894-9611 x 2369 FAX: 806-894-1549 Email: TWinders@SPC.cc.tx.us ********************************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (OSF1) Comment: Made with pgp4pine 1.76 iEYEARECAAYFAjsjszEACgkQTPuHnIooYbxl5gCfX63Ol9hkl2AfFvos69jVZUpp HG8An3YusnPS+0NXFXBHLN5GU9SHeaAl =EUsG -----END PGP SIGNATURE-----