Does Your Uplink Multicast?

knof asks: "It seems like the big ISPs want to waste bandwidth, because they don't support technologies like multicast, at least here in Germany. As far as I know the only way to get multicast access is to setup a feed to the MBone or to use the DFN (Deutsches ForschungsNetz) if you're a student, which I am not. Is it expensive or difficult for ISPs to make their networks multicast aware? How is the situation in other countries? And are there any ISPs in Germany which are Multicast friendly?" It would be interesting to know how much of the Internet is capable of multicasting. Even here in the US, I don't believe it's getting widely used. Is this changing?

Comments

Multicast

[Tuzanor]

over the internet, multicast is a pretty much a useless feature. A lot of the time it won't even work because a lot of routers have been configured to ignore multicast addresses to save space on the routing tables. If only early on they knew that streaming video/audio was coming...

Considering how many IPs are wasted for multicast, its really no wonder why we're at a shortage right now. Whoever sorted the current IP space needs to be shot in the HEAD (so that his brain may NEVER be brought back). 16 million IPs for loopback? excuse me? out of that whole block the only one that gets any use is 127.0.0.1

Those Class D and E spaces could have given us many usefull IPs...and now...useless.

Re:Multicast

[Harumuka]

a lot of routers have been configured to ignore multicast addresses

Can you provide a reliable source to back up this claim? Quoting directly from W. Richard Steven's Unix Networking Program, Volume 1, page 901:

The end result is that the multicast datagram sent on the top LAN also gets transmitted as a multicast datagram on the lower LAN. This occurs even through the two routers that we show attached to these LANs, and all the Internet routers between these two routers, are not multicast capable. (Emphasis mine)

Of course, ignoring multicast address is a different thing, but I see no evidence to back up your claims.

Re:Multicast

[Tuzanor]

You've only quoted the"end result" how did he get this? there are, of course, hacks to everything.

Re:Multicast

[Harumuka]

Basically, a tunnel is created between one of the multicast-capable hosts on each LAN using the MBone. The MBone is similar in concept to the 6Bone, which I've successfully used for connecting as an IPv6 host though my ISP doesn't support it. Such is the beauty of virtual tunnels.

Re:Multicast

[Tuzanor]

well in that light, multicast can work because its tunneled...its not actually "multicasting" over the internet, its just multicasting through the networks at each end of the tunnel. Its kind of like how they got old SPX only games to run over the internet, by having special software that tunneled it to an internet server making it look like one big IPX/SPX LAN...quite ingenious. But it doesn't work for everybody unless they have the software.

Re:Multicast

[aozilla]

Considering how many IPs are wasted for multicast, its really no wonder why we're at a shortage right now.

We don't really have a shortage of IP addresses. Any machine connected to the internet which doesn't have an IP address, doesn't have one for reasons other than a shortage. Some of us might like to have multiple IP address for a single machine, or would like to keep our IP address even when we're not connected to the internet, but doing this is never an efficient solution anyway.

Re:Multicast

[Tuzanor]

True, the "shortage" isn't because of one reason, its because one organization grabs 16 million class A addresses and doesn't sell/lease out the ones they don't use, and its because wireless devices using IPs when they could really just be NATed, and its because of wasting them using useless features, etc,etc,etc

Re:Multicast

[aozilla]

What I'm saying is that there is no shortage at all. I know of no example of someone with a legitimate need for an IP address who can't get one.

Re:Multicast

[Tuzanor]

yet. but soon they may get mor expensive

Re:Multicast

[MikeBabcock]

But you can no longer purchase address blocks from IANA, for example (IANA or ARIN? I forget now) without purchasing a /19 block -- that's a lot of wasted addresses if you just want your own permanent /24 or /27 ...

Re:Multicast

[aozilla]

But you only need to purchase from IANA if you need portable address space. If you only need a /24 or /27, you should be purchasing it from your ISP. We don't need routing tables clogged with /24s and /27s. If you need portability, use DNS. If you need reliability, use DNS.

Multicast on an ISP is bad

[Snowfox]

Multicasting is bad. A lot of games use it, and that could chew up a LOT of bandwidth, certainly enough to saturate the 10mbit NIC or USB connection used for many broadband setups.

Even in our own office, I wish we could kill multicasting. We make games here, and in the evening, a lot of groups of guys are playing games that spew enough multicast packets to bring our 100mbit network to its knees. (Yes, we're using switches, not hubs.) Playstation 2 debugging uses a network connection between the PS2 and PC. Debugging becomes slow as molasses unless you unplug your uplink or put a 2nd NIC in and connect to your PS2 TOOL directly.

Re:Multicast on an ISP is bad

[zsazsa]

Do you mean broadcast packets?

Re:Multicast on an ISP is bad

[sparetiredesire]

Do you even know what "multicast" is? Multicast is more efficient for multi-party communication. If you sent seperate packets to each of K users you'd use K times the bandwidth on your outgoing link. This is what happens if you use unicast instead.

With multicast you send a single packet, and the network replicates it at the latest possible point. What would you propose as a more efficient means?

Re:Multicast on an ISP is bad

[knof]

maybe it's not good for games, but for multimedia stuff (video streaming) it would save a lot of bandwith

Re:Multicast on an ISP is bad

[Anonymous Coward]

Let me get this straight:

You're in the business of making money by selling video games, and yet are offended when people play them when it happens to interfere with your odd working hours.

Do you simply fail to realize that you're to blame for this percieved problem?

Re:Multicast on an ISP is bad

[Snowfox]

Multicasting is bad. A lot of games use it, and that could chew up a LOT of bandwidth, certainly enough to saturate the 10mbit NIC or USB connection used for many broadband setups.

Mental speedbump. I was reacting to broadcast, not multicast, as AC points out.

Re:Multicast on an ISP is bad

[Snowfox]

You're in the business of making money by selling video games, and yet are offended when people play them when it happens to interfere with your odd working hours.

Need to calm down, dude. I'm bugged by the games slamming on the net bandwidth, not the games themselves or the people playing the games. If networking were implemented properly in these games (or our switches were smart enough not to just broadcast multicast packets, if that's the problem), it wouldn't affect me at all.

Re:Multicast on an ISP is bad

[CharlieG]

1)Your thinking Broadcast
2)Multicast can be great, if you can get your LAN guys to get it on line, and keep it there

We have an application that has about 300 - 500 simultaneous users here at the office - Updates often have to go to ALL the users screens right away. Multicast is the only effective way to go. We have problems with segments going down - so we end up having to put up Multicast tunnels, but that leads to echo problems

Sigh

Re:Multicast on an ISP is bad

[adjuster]

Even in our own office, I wish we could kill multicasting. We make games here, and in the evening, a lot of groups of guys are playing games that spew enough multicast packets to bring our 100mbit network to its knees. (Yes, we're using switches, not hubs.)

You need switches that support IGMP spoofing, then. If the traffic really is multicast, and not broadcast, IGMP spoofing is what you're looking for.

<KARMA-WHORING>
Take a look here-- it's a pretty decent article on IP multicast (not really technical-- just buzz-laden). Some rudimentary technical information is in here.
&lt/KARMA-WHORING>

Re:Multicast on an ISP is bad

[Anonymous Coward]

Multicast still uses bandwidth and is pretty close to broadcast in its implementation.

10 OSes on 1 computer.

[Blaede]

http://www.hyperos2002.com/

Multicast is dead.

[Anonymous Coward]

Film at eleven.

For all of us who are Multicast illiterate

[Mustang Matt]

A quick search on google revealed this great article!

Multicast Explanation

Lack of support in Canada too

[velkro]

I asked both AT&T and Bell about multicast - both indicated that thier backbones do not support multicast... and they don't seem to have plans to enable it anytime soon.

Multicasting, the MBone, et al.

[jd]

First, if you ask on the MBONE mailing list for a feed, they'll tell you to go to your ISP, and that if -they- don't support it, well, tough.

Then, if you go to your ISP, and you're VERY lucky, they'll tell you to go to the MBONE mailing list. Most ISPs I've talked to just tell you to go to hell.

The conclusion I came to is that the existing multicast structure that exists (which is all native PIM, or near enough) is controlled and run by a Royal Priesthood, and only The Worthy (and very rich) can pay a tithe great enough to appease the Net Gods.

(UUNET is a great example. Sure, they'll provide multicast! Provided you pay $10,000+, for a high-speed link. For the cheaper nodes? No f* way! Peasents don't deserve such technology!)

Given this attitude, can you SERIOUSLY wonder why the less-knowledgable view technology with suspicion? It's not exactly as though they're being encouraged to see it as a powerful friend.

Getting on with the question of "is it expensive?" The correct answer is "no - unless your admin charges $100,000 per character typed".

For those who want to convince their admins to enable multicasting, but wish to use less force than a Daisy Cutter, here are the simple instructions to set things up:

• Enable multicasting and multicast routing in the kernel. If you wish to use PIM, also enable PIM-1 and/or PIM-2.
  
• Recompile the kernel, install, and reboot.
  
• On reboot, you'll now see additional messages, informing you that multicast routing is present. You'll also see an protocol listed (IGMP), which is used for communicating group information between multicast sites.
  
• So far, so good. For most computers, all you need to is add the multicast group address to the routing table, like so: route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0 (or whatever device you're using)
  
• To check that this is working, ping the network address like so: ping -c 2 224.0.0.1. All multicast-enabled computers on your LAN should respond, with their OWN address, not the multicast group address.
  
• On the machine to be used as a router, you need to do two more steps. You need to enable packet forwarding (which, if it's being used as a router, will already be done. DUH!)
  
• The router will also need EITHER multicast routing enabled in the router software (if the option exists), OR a software router such as PIMD, MROUTED, or GATED 5.0. (I strongly advise AGAINST GATED. It's closed-source, the development cycle was suspicious, the cost is phenominal, and it really does nothing that the other, free (in all senses) software can't do anyway.)
  

And that is it! The sum total of the arcane art of multicasting.

Those who are used to games are probably much more familiar with broadcasting, as very very few games use multicasting. Multicasting would be useful for games, as it would seriously reduce the network load, but as network games are typically server-based, rather than distributed, there's really nothing to multicast, right now.

The Internet backbone is, essentially, entirely multicast-ready. There is no "virtual" network of tunnels, any more, but rather one multicast cloud, which the ISP merely has to belong to. The main reasons ISPs don't join are as follows:

• There's very little software that uses it, so there's nothing to promote it with.
  
• There's next to zero information on it, making tech support a hazardous occupation for mom & pop ventures.
  
• There's very little demand for it, because most services which would be ideal over multicast (eg: streaming audio/video) is all done over unicast. There's therefore absolutely no incentive for users to look any further.
  
• It's impossible for advertisers and servers to exploit financially, as there's no means of telling how many people are accessing the service. There's ONE output stream, regardless of the number of people receiving.
  
• The Internet backbone providers aren't keen on Joe & Jane Q Public using multicasting, as there are very few multicast addresses available. The addressing (for IPv4, anyway) could not support an explosion of interest in multicasting.
  
• Cable companies are not going to provide a service which seriously competes with their own regular TV service. They may be stupid, but they're not crazy.
  
• Microsoft provides only a crippled multicast service with Windows (no multicast routing, and no multicast loopback), so software shops that gear to Microsoft OS' tend not to bother with it.
  
• Because multicasting is done over dynamic addresses, you can't filter it's content, making it utterly repugnant to virtually all governments.
  
• There are no certifications in multicast technology, making it a valueless skill for students or employees to learn. If it can't be quantified or evaluated, employers are generally uninterested.
  
• Multicasting is the Internet's last, best-kept secret. The moment the prawn industry cottons onto the fact that they can stream explicit video to many more people, for far less money on their part, in a way that cannot be blocked without blocking multicasting entirely, is the moment that the entire political, legal and religious scenes become irrelevent. (As if they weren't, already.) This would drive not so much as the final nail into the coffin of control, but it would throw in a 30-tonne stake for good measure.
  
  

  
  THESE are the reasons multicasting isn't in general, wide-spread use, not the cost (there isn't one), and not the complexity (there isn't any).

ISP peering agreements and multicast.

[kbyrd]

I attended a conference (Stardust) several years
ago and at one of the discussion groups several
ISPs were involved. A common concern was how
to charge and be charged by their peers for
multicast traffic.
Simple Example:
ISP A and B peer with each other, the ship bits
both directions all month long. At the end of
the month, they settle up. With unicast traffic,
the number of bits comming over the peering
connection coorosponds to the number of bits
shipped inside a given ISPs network.
With multicasting, A send a single multicast
stream to B, but B has to repeat it at several
points to get it to various dial-up and broadband
POPs and the customers connected to those POPs.
A can send a single stream which cause much more
load on Bs network.

Re:ISP peering agreements and multicast.

[Nemosoft Unv.]

This point is practically moot, since even if A sends a multicast to B, once it arrives at B it only needs to be redistributed on B's local network, which doesn't cost them a single penny more in their peering contract.

In fact, if A and B support proper multicast it will save them bits, because if A has an interesting broadcast and 10 listeners from B want to hear it, they have to transmit it only once from A to B, not 10 times.

Re:ISP peering agreements and multicast.

[kbyrd]

It's not quite moot. It depends on what you mean by "B's local network". Imagine an national ISP with either has their own long-haul links between POPs or piggy-backs on someone else's links between POPs. A can ship B one bit that needs to be duplicate to (potentially) many POPs those long-haul lines can be a limited resource.

My point was that ISPs were confused about how multicasting and how it affected thier current price/revenue models.

Re:ISP peering agreements and multicast.

[MikeBabcock]

However, had the same bit been transfered without multicast, it would have been sent once for each of those links and the _same_ amount of traffic would have been generated on ISP B's local network. The only reduction (in your example) is for the link between A and B.

I can see how it would be difficult to inter-charge for this, but its not that difficult to track memberships of multicast addresses and log how many of your users you're going to send the packet to.

sprintlink & broadcast.com

[akb]

From the Sprintlink multicast page "... all SprintLink customers can request to have multicast services enabled, completely free of charge."

Sprintlink sells t1 - OC48, no consumer services. But if your ISP peers with them that's one less excuse they have not to give it to you. I still wouldn't hold my breath.

Last I knew broadcast.com attempted to stream its content over multicast and reported a 5% success rate. They're big enough to use this as a ballpark figure for the percentage of the 'net that has multicast (which is pretty sad imho). They have a list of their multicast affiliates, ISP's that can receive multicast events and programming.

Re:sprintlink & broadcast.com

[MikeBabcock]

When you consider how efficient multicast is for broadcasting of live event video and audio and/or for peer discovery (such as a non-centralised-server based P2P package), its a shame networks don't support it.

All things considered, I was unaware until the last year or so how poorly multicast was supported on the Internet. I must admit that I've come across very little good documentation or code examples in my travels either although I've come up with quite a few.

chicken and egg

[Bullhead]

thing is the whole multicast thing is a bit chicken and egg at the mo.

ISP's, although they are playing with it in the backbones and some have fully multicast enabled backbones have no real need to roll it down to the end user because there aren't any (many) apps/broadcasts out there that use it!

And content providers don't bother multicasting content as the software isn't up to scratch and the ISP's don't support it down to the customer network.

Then there is the issue that even if the ISP supported it down to the customer network that most customer networks aren't setup for multicast on a LAN level. Might not be an issue having an extra E1/T1 of broadcast trffic on most LAN's but some people wouldn't be too happy about it.

At present in the UK's major peering point more than 20 isp networks exchange multicast traffic (about 20% of total members). Which is a start...

Also new developments are under way in the addressing and management technology behhind multicast. In particular PIM-SSM (source specific multicast) that allows requests to be made on source,group (S,G) broadcast rather than just anyone,group (*,G) will change the way multicast can be used on the internet, as unicast addresses will become the decriminater for the group. This gives each broadcaster many multicast groups to broadcast too unlike the 255 addresses AS's get now.

Again though this requires IGMPv3 which i don't think will be making an apperance in any M$ IP stack anytime soon!

Bottom line is the technology rocks but the current financial climate seems to have put projects like multicast on a back burner...