|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.
|WikiProject Computing / Networking||(Rated C-class, Low-importance)|
|The content of CastGate was merged into IP multicast on 21 September 2016. For the contribution history and old versions of the redirected page, please see ; for the discussion at that location, see its talk page.|
- 1 Moving Addressing to Routing Schemes
- 2 Cleanup notice
- 3 Rewrite
- 4 Complete update started
- 5 Inappropriate Tone
- 6 Integrate these paragraphs?
- 7 Hoot-n-holler?
- 8 Applications and Protocols?
- 9 Small fix for Reliable Multicast
- 10 Layer 2 support
- 11 Small fixes for Reliable Multicast and Layer 2 support
- 12 Steve Deering
- 13 contrary to carrier business models
- 14 Broken Link?
- 15 Addressing Section
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)
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)
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...22.214.171.124 12:01, 24 August 2005 (UTC)
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
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 126.96.36.199 was me. It still needs work, but it's better than it was. Stephen.frede 10:14, 11 July 2006 (UTC)
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
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)
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.
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)
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 188.8.131.52 07:01, 27 October 2006 (UTC)
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)
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)
- 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)
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)
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)
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)
- 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)
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 184.108.40.206 (talk) 00:35, 16 March 2010 (UTC)
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 220.127.116.11 (talk) 16:55, 21 January 2013 (UTC)
There is no such thing as anycast addressing in IPv4.
This revision was partly right:
I would suggest to remove the addressing section, or at least the part on anycast.
- 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)