Talk:IP multicast

This is the talk page for discussing improvements to the IP multicast article.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Networking Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

Moving Addressing to Routing Schemes

I think the Addressing section should be moved. At least some of it. Those things relevant to multicasting are ok, but anycasts or unicasts have hardly anything to do with IP Multicasting. Opinions? -def Mon Jul 24 2006

I moved that section to the IP address article. Maybe it is not the best location, but it fits better there than here. Sega381 (talk) 23:59, 20 August 2013 (UTC)[reply]

Cleanup notice

Gah. Product boosting and advertising blather. Not the hottest writing either. I don't have time today to clean it up, but I'll try to take a crack at it Real Soon Now. Anville 21:58, 22 August 2005 (UTC)[reply]

Tossed in a very brief overview on the Temp page. Provides a brief definition and some vendor-neutral technical details. Since I wrote the whole thing myself, it should be immune to copyright violations. Of course, that doesn't necessarily mean it's good enough quality...196.41.167.243 12:01, 24 August 2005 (UTC)[reply]

It seems that the writer of this article does not have a good grasp of the English language. I would prefer an article written by a native speaker.

<SymlynX> I haven't created this document, but it makes sense to me to have distinct documents for IP Multicast and the abstract meaning of Multicast, so I'm positive for a merge of the IP Multicast part in Multicast into here. What do you think?

@SymlynX: Makes sense to do so...

Seems good. --anonymous

Rewrite

I have merged the content from Multicast, but ended up rewriting most of it. Sadly wasn't signed in when I made the change, but 2006-07-11 21:08:36 203.2.96.1 was me. It still needs work, but it's better than it was. Stephen.frede 10:14, 11 July 2006 (UTC)[reply]

Complete update started

It's going to take quite a bit of doing as IP multicast is a pretty large subject, but I made a start at it today in the first few sections. Long way to go and a lot of ground to cover, but hopefully I can get it done. Hopefully none of the past editors take offense to my going gung ho, but I hope you'll find my contributions worthwhile. I think you'll find I have a fair bit of multicast expertise, but feel free to challenge me if there is something major you don't like. I do expect to have some bits and pieces fixed up by others as my writing can sometimes be a little hectic and not always well organized as I move from topic to topic. [ update: silly cookie, expired, this is me jtk ]

While at it, multicast security [MSEC] is another topic missing. --anonymous

Inappropriate Tone

The use of second-person conversational tone as well as several other unencyclopaedic statements is inappropriate. The text of this article be revised.

For example: "You might now be wondering about the efficiency..."

go ahead and change the tone where you find it lacking, but please be careful with the technical details, that is the part I am focusing on jtk Sun Jul 23 03:41:15 GMT 2006

Changed a few of the tone thingies -def Mon Jul

Some of the multicast security work (particularly relatated to crypto and group authentication) might be well suited for a separate article. Much of that work is academic and not widely deployed. I know less about it, so if someone wants to take a stab at it go for. Though I can envision that being a separate article as I said. jtk Fri Sep 1 15:52:49 GMT 2006

Integrate these paragraphs?

The following text blocks stem from the Multicast document but since they are about IP Multicast they don't belong there. Feel free to integrate in this document. -SymlynX 11:09, 7 September 2006 (UTC)[reply]

Link local multicast, where IP Multicast packets are sent to groups of hosts on the same physical or virtual data link layer, does not require complex routing, and is therefore much more widely deployed. It is used in IPv6 for address resolution, and in zeroconf networks for service discovery, name resolution, and address conflict resolution, replacing inefficient broadcast protocols.

Multicast security is a major issue. Standard, practical, communications security solutions normally employ symmetric cryptography. But applying that to IP Multicast traffic would enable any of the receivers to pose as the sender. The IETF MSEC workgroup is developing security protocols to solve this problem, mostly within the architectural framework of the IPsec protocol suite.

IPsec cannot be used in the multicast scenario because IPsec security associations are bound to two hosts and not many. IETF proposed a new protocol TESLA, which is quite convincing and flexible for multicast security.

Multicast security has been an active area of interest for some time. Standard, practical, communications security solutions normally employ symmetric cryptography. But applying that to IP Multicast traffic would enable any of the receivers to pose as the sender. The IETF MSEC workgroup is developing security protocols to solve this problem, mostly within the architectural framework of the IPsec protocol suite.

Hoot-n-holler?

Can anyone say what a "hoot-n-holler" system is? The article refers to it, but Wikipedia doesn't have an entry.... --Alvestrand 06:41, 22 September 2006 (UTC)[reply]

Found a def. [1]. Now to make an article from it... --Alvestrand 06:43, 22 September 2006 (UTC)[reply]

Applications and Protocols?

There are currently no links between this topic and the topics covering applications using multicast.

At least the "Applications" paragraph could note that "multicast is supported by protocols such as Real Time Streaming Protocol and applications such as Windows Media Player". I'd add this myself, but the discussion page indicates that people have spent quite some time tidying this page up.

Thog 203.59.28.111 07:01, 27 October 2006 (UTC)[reply]

Small fix for Reliable Multicast

Under Reliable Multicast is says "...can request that the packet be resent using a simple unicast connection." What connection ? A packet resend does not need any connection. Is the mising packet resent over TCP ? --Xerces8 13:20, 31 January 2007 (UTC)[reply]

Layer 2 support

I miss details about multicast implementation on Layer-2 (ethernet switches). Is it in another article ? I'm am especially interested about low-cost and SoHo switches. --Xerces8 13:20, 31 January 2007 (UTC)[reply]

I've added some more information on layer-2 implementation. I've not added any specific vendor information, but AFAIK most low-cost switches will not implement IGMP snooping, but many low-end switches (not low cost) of 3com, Cisco, etc, do. --Javifs November 2007 —Preceding comment was added at 16:11, 21 November 2007 (UTC)[reply]

Many low end switches support neither IGMP snooping nor multicast flooding. They simply don't pass on multicast. I have just finished troubleshooting DLNA traffic which is Upnp/Multicast. My Tenda switch doesn't pass multicast under any circumstances and my TP-Link only passes multicast until it has built its Mac table. So I am looking for a new switch. D-Link tell me for example that only their managed switches ie mid range and above support either or both of multicast flooding and IGMP snooping. --PaulC January 2013

This is WP:OR. I think you are also mistaken. Or your switch is broken or "Many" is a gross exaggeration. I have reverted your change. If you want to resore it, please find a WP:RS that supports this. -—Kvng 03:28, 19 January 2013 (UTC)[reply]

Small fixes for Reliable Multicast and Layer 2 support

As Xerces8 pointed out above under Reliable Multicast it says "...can request that the packet be resent using a simple Unicast connection." What connection? A packet resend does not need any connection. Is the missing packet resent over TCP?

According to PGM's co creator, PGM design was to re-multicast missing packet information, thus avoiding an implosion of replacement requests with corresponding Unicast packet replacement data. Also, Hulkster added newer information about PGM-CC. PGM-CC is a congestion control attempt that steps the bandwidth down to the worst receiver in the group. This is controversial because the other group members are made to suffer the step down and resultant quality loss.

About the details of implementation on Layer-2: IP Multicast is mapped into corresponding Ethernet address space and even low quality SOHO switching routers pass the Multicast datagrams to the fellow downstream (neighboring) interfaces. Better quality SOHO routers (like Linksys and D-link) also snoop for IGMP V2(V3) join messages (IGMP Version 3 support in newer units). When received they pass the IGMP messages to the upstream interface and flow the IP Multicast to the end users as long as someone remains in the group.

Higher end routers also do a routine query to make sure someone is still interested (joined) to the group. Because IGMP is a connectionless protocol, multiple IGMP messages are sent to be sure that all interested parties have heard the (still there?) message. This scheme proves to be problematic in a SOHO radio LAN environment because packet loss is so high in these environments that even several (still there?) messages might not be heard causing the group to be shut down by the SOHO router. Hulkster will edit the Ethernet section as necessary.

--Hulkeypoo 16:27, 3 October 2007 (UTC)[reply]

Steve Deering

Shouldn't this page mention that Steve Deering invented IP Multicast and developed it as his Ph.D. thesis? -- Steve Casner —Preceding unsigned comment added by Slcasner (talk • contribs) 19:59, 25 May 2008 (UTC)[reply]

We probably should, though we'll need some sourcing for verification. I would avoid the term "invented" (perhaps proposed the concept?). /Blaxthos ( t / c ) 21:40, 25 May 2008 (UTC)[reply]

contrary to carrier business models

another reason multicast is rarely available "to the end user" is that offering it is contrary to the business model of a carrier who charges for bandwidth. I don't have a citation for this sensible obersvation however.

Torrent-like protocols (such as torrent) that self-organize to reduce long-haul bandwidth, and reduce the load on an originating server, have eased the pain somewhat too. —Preceding unsigned comment added by 75.87.135.149 (talk) 00:35, 16 March 2010 (UTC)[reply]

Broken Link?

The second-to-last external Reference, "(Frequently Asked Questions (FAQ)), Multicast Tech, retrieved 2010-11-18." points to http://www.multicasttech.com/faq/. The site is in German, and (from my limited knowledge of German) does not appear to have anything to do with IP multicasting. — Preceding unsigned comment added by 205.210.223.133 (talk) 16:55, 21 January 2013 (UTC)[reply]

Addressing Section

There is no such thing as anycast addressing in IPv4.

This revision was partly right:

http://wiki.riteme.site/w/index.php?title=IP_multicast&oldid=514322068

I would suggest to remove the addressing section, or at least the part on anycast.

--Gregory.lussier (talk) 13:15, 31 May 2013 (UTC)[reply]

Well, the article should cover IP in general, not just IPv4. I believe I have distinguished the two, to address your concern. Kbrose (talk) 17:43, 31 May 2013 (UTC)[reply]

I moved that section to IP address, since it talks about different addressing methods, including multicast, which is the only focus of this article. That section was much broader in scope than this article. Sega381 (talk) 00:01, 21 August 2013 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 11 external links on IP multicast. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:34, 10 November 2017 (UTC)[reply]

Deployment

Multiple statements in the Deployment section have been marked as unverified for some time. I went to find some sources to support these statements and was not immediately successful. I found things like this instead. IP multicast is available on most enterprise-grade network equipment. It is generally not enabled by default and my experience is that it is not routinely enabled on enterprise networks. No one now expects IP multicast to be made available over large networks such as the internet. Intrinsic reliability issues with multicast delivery limit the sorts of applications that can use it effectively. Content delivery networks are providing services we once thought would be delivered via multicast. ~Kvng (talk) 15:53, 3 December 2017 (UTC)[reply]

Each application must not join

In the "Routing" section, we find the statement:

"Each host (and in fact each application on the host) that wants to be a receiving member of a multicast group [...] must use the Internet Group Management Protocol (IGMP) to join"

But at least in Linux which is one of the most common network device operating systems, that is not a true statement. Indeed, it suffices that one application joins for all applications to be able to receive the multicast stream.

2001:1BA8:1614:E800:E898:43BD:1005:28D9 (talk) 07:31, 22 July 2020 (UTC) Daniel Janzon[reply]

To describe this from a network perspective, the parenthetical is unnecessary and potentially distracting. What applications are required to do to receive multicasts is OS dependent. I have deleted the parenthetical. ~Kvng (talk) 13:22, 25 July 2020 (UTC)[reply]