Talk:IP multicast

message: 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)
thread_title: Moving Addressing to Routing Schemes

message: 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)
thread_title: Cleanup notice

message: 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)
thread_title: Rewrite

message: 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)
thread_title: Integrate these paragraphs?

message: 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)
replies: text: Found a def. . Now to make an article from it... --Alvestrand 06:43, 22 September 2006 (UTC)
thread_title:  Hoot-n-holler? 

message: 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)
thread_title:  Applications and Protocols? 

message: 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)
thread_title:  Small fix for Reliable Multicast 

message: 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)
replies: text: 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)

text: 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)
thread_title:  Layer 2 support 

message: 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)
thread_title:  Small fixes for Reliable Multicast and Layer 2 support 

message: 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)
replies: text: 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)
thread_title: Steve Deering

message: 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)
thread_title:  contrary to carrier business models 

message: 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)
thread_title:  Broken Link? 

message: There is no such thing as anycast addressing in IPv4.
This revision was partly right:
http://en.wikipedia.org/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)
replies: text: 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)
replies: text: 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)
thread_title:  Addressing Section 

message: 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:
*Added archive https://web.archive.org/web/20110526111518/http://www.nordu.net/conference2006/presentations/We11_NORDUnet2006.pdf to http://www.nordu.net/conference2006/presentations/We11_NORDUnet2006.pdf
*Added  tag to http://mediatools.cs.ucl.ac.uk/nets/mmedia/
*Added archive https://web.archive.org/web/20071126235623/http://www.venaas.no/multicast/ssmping/ to http://www.venaas.no/multicast/ssmping/
*Added archive https://web.archive.org/web/20070826161743/http://www.kloosterhof.com/~wilbert/igmpv3.html to http://www.kloosterhof.com/~wilbert/igmpv3.html
*Added  tag to ftp://parcftp.xerox.com/pub/net-research/ipmulti/
*Added archive https://web.archive.org/web/20071224133547/http://netweb.usc.edu/pim/ to http://netweb.usc.edu/pim/
*Added archive https://web.archive.org/web/20070909152315/http://www.nexthop.com/products/gated.html to http://www.nexthop.com/products/gated.html
*Added archive https://web.archive.org/web/20071015124705/http://antc.uoregon.edu/GATED/ to http://www.antc.uoregon.edu/GATED/
*Added archive https://web.archive.org/web/20071203150138/http://www3.ietf.org/html.charters/rmt-charter.html to http://ietf.org/html.charters/rmt-charter.html
*Added archive https://web.archive.org/web/20071214221047/http://www.ietf.org/html.charters/magma-charter.html to http://ietf.org/html.charters/magma-charter.html
*Added archive https://web.archive.org/web/20071202041753/http://www.ietf.org/html.charters/pim-charter.html to http://ietf.org/html.charters/pim-charter.html
*Added archive https://web.archive.org/web/20070127090246/http://www.ietf.org/html.charters/ssm-charter.html to http://ietf.org/html.charters/ssm-charter.html
*Added archive https://web.archive.org/web/20071216145244/http://www.ietf.org/html.charters/msec-charter.html to http://ietf.org/html.charters/msec-charter.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 08:34, 10 November 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Deployment 

message: 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)
replies: text: 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)
thread_title:  Each application must not join