Talk:IP Multicast
From Wikipedia, the free encyclopedia
[edit] 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
[edit] 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)
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)
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
[edit] 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)
[edit] 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
[edit] 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
[edit] 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.
[edit] 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)
- Found a def. [1]. Now to make an article from it... --Alvestrand 06:43, 22 September 2006 (UTC)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
[edit] 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)
- 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)
