Multicast Internet Route table.
Members I have few questions related to Multicast deployment in the internet today. 1: Does all the ISP's provide Multicast Routing by default? 2: Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?
On Tue, 2 Sep 2014, S, Somasundaram (Somasundaram) wrote:
Members I have few questions related to Multicast deployment in the internet today.
Inter-domain I am assuming.
1: Does all the ISP's provide Multicast Routing by default?
Probably not a majority, but it is found on research networks like Internet2, GEANT, etc and any of their member networks.
2: Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?
One such place, long running: https://nic.nrc.ca/bgp-mcast/bgp-active.html There may be others on the networks mentioned above... wfms
On Tue, 2 Sep 2014 04:47:37 +0000 "S, Somasundaram (Somasundaram)" <somasundaram.s@alcatel-lucent.com> wrote:
1: Does all the ISP's provide Multicast Routing by default?
No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding.
2: Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?
Marshall Eubanks at one time probably maintained the most comprehensive IP multicast status pages at http://www.multicasttech.com/status (no longer available). I've not seen nor heard from Marshall in a long time so I wouldn't expect this to come back any time soon. Sadly I don't know of any suitable replacement, but you might find some of that by searching here, if nothing else using the router proxies to examine status by hand: <http://noc.net.internet2.edu/> CAIDA used to do some, but I'm not sure they have anything active any longer, browsing their tools and data may turn up some hints to other work. The once NLANR inspired and run Beacon project hasn't completely died out, there is this I found at ja.net for instance: <http://www.beacon.ja.net/> Interdomain IP multicast has practically since the beginning been a notoriously niche and limited service compared to unicast service. There are a handful of reasons for that, but I think you will find it becoming decreasingly available rather than more so on interdomain basis. John
14 years at Verizon Wireless and I despised the crop of multicast products that seemed to pop up from time to time. Even in a fully controlled network multicast remains at best black magic. There are ways to make it more reliable and prevent people from ruining the setups especially for PIM type setups, but I would agree with others, unicast has better advantages though you have to keep up with the bandwidth curve. Content delivery systems moving the content closer to edge customers makes this less of a problem as well. Torrent style distribution appears to be particularly effective as long as you can maintain a pool of users to distribute the content. Blizzard has made good progress using this for game updates will a fallback to http if you can¹t get the content via torrents. On 9/2/14, 6:46 AM, "John Kristoff" <jtk@cymru.com> wrote:
On Tue, 2 Sep 2014 04:47:37 +0000 "S, Somasundaram (Somasundaram)" <somasundaram.s@alcatel-lucent.com> wrote:
1: Does all the ISP's provide Multicast Routing by default?
No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding.
2: Is there any placeholder where one can get to know the Multicast Internet Route table (usage, stability etc) just like Unicast Route table (http://bgpupdates.potaroo.net)?
Marshall Eubanks at one time probably maintained the most comprehensive IP multicast status pages at http://www.multicasttech.com/status (no longer available). I've not seen nor heard from Marshall in a long time so I wouldn't expect this to come back any time soon.
Sadly I don't know of any suitable replacement, but you might find some of that by searching here, if nothing else using the router proxies to examine status by hand:
<http://noc.net.internet2.edu/>
CAIDA used to do some, but I'm not sure they have anything active any longer, browsing their tools and data may turn up some hints to other work.
The once NLANR inspired and run Beacon project hasn't completely died out, there is this I found at ja.net for instance:
Interdomain IP multicast has practically since the beginning been a notoriously niche and limited service compared to unicast service. There are a handful of reasons for that, but I think you will find it becoming decreasingly available rather than more so on interdomain basis.
John
On Tue, 2 Sep 2014, Corey Touchet wrote:
14 years at Verizon Wireless and I despised the crop of multicast products that seemed to pop up from time to time. Even in a fully controlled network multicast remains at best black magic. There are ways to make it more reliable and prevent people from ruining the setups especially for PIM type setups, but I would agree with others, unicast has better advantages though you have to keep up with the bandwidth curve.
I can tell you that the IPv4 multicast routing table size has been pretty much flat (stable to declining slightly) for the past several years. Right now, I see a total of just under 3,800 IPv4 multicast routes through Internet2 and other research/education networks, and that number hasn't changed much in probably 2-3 years. I don't get any multicast routes from my commodity Internet providers. Several years ago (2008-ish), I was receiving around twice that many multicast routes, so it has died off significantly in the long view. External IPv4 multicast traffic has been pretty much zilch for quite some time, from my viewpoint. jms
On Tue, Sep 2, 2014 at 11:29 AM, Corey Touchet <corey.touchet@corp.totalserversolutions.com> wrote:
14 years at Verizon Wireless and I despised the crop of multicast products that seemed to pop up from time to time. [...] Content delivery systems moving the content closer to edge customers makes this less of a problem as well. [...] Torrent style distribution appears to be particularly effective as long as you can maintain a pool of users to distribute the content.
Hi Corey, Would it be fair to say that: Unicast delivery from distributed caches (e.g. CDNs, Content Delivery Networks) and/or unicast peer to peer transfer is more effective in nearly all applications where interdomain multicast routing is a candidate solution? If that's true, would it be useful for ISPs to build some kind of generalized multi-layer streaming cache system that any end-user application could make use of? Build caching into the system's capabilities instead of it being hit or miss depending on who pays for a CDN? Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> Can I solve your unusual networking challenges?
On 09/02/2014 05:46 AM, John Kristoff wrote:
On Tue, 2 Sep 2014 04:47:37 +0000 "S, Somasundaram (Somasundaram)" <somasundaram.s@alcatel-lucent.com> wrote:
1: Does all the ISP's provide Multicast Routing by default?
No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding.
Why would that be, are network devices not able to support multicast? I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
It is not the network devices per se, it is additional configuration, security, MSDP peering, etc, i.e. OPEX Business justification for such effort is not obvious, (most of multicast deployments I have done in my previous life were because I loved the technology, not because of business needs :)) Cheers, Jeff -----Original Message----- From: Octavio Alvarez <alvarezp@alvarezp.ods.org> Date: Tuesday, September 2, 2014 at 8:43 AM To: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: Multicast Internet Route table.
On 09/02/2014 05:46 AM, John Kristoff wrote:
On Tue, 2 Sep 2014 04:47:37 +0000 "S, Somasundaram (Somasundaram)" <somasundaram.s@alcatel-lucent.com> wrote:
1: Does all the ISP's provide Multicast Routing by default?
No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding.
Why would that be, are network devices not able to support multicast?
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
On Tue, 2 Sep 2014, Jeff Tantsura wrote:
It is not the network devices per se, it is additional configuration, security, MSDP peering, etc, i.e. OPEX
Business justification for such effort is not obvious, (most of multicast deployments I have done in my previous life were because I loved the technology, not because of business needs :))
Ditto, although business needs played a part as well. :) wfms
On Tue, 2 Sep 2014, Octavio Alvarez wrote:
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
I have set up interdomain routing connecting both to a few peers and a Tier1 transit provider. Not many non-research networks to be seen. Also, since we didn't use it it kept breaking and I had to fix it every two years or so, where it probably had been down for months. I don't believe in Internet-wide multicast happening in current incarnation, it's just too fragile and too few people are using it. It wouldn't scale either due to all the state that needs to be kept. -- Mikael Abrahamsson email: swmike@swm.pp.se
Thus spake Mikael Abrahamsson (swmike@swm.pp.se) on Tue, Sep 02, 2014 at 06:05:42PM +0200:
On Tue, 2 Sep 2014, Octavio Alvarez wrote:
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
I have set up interdomain routing connecting both to a few peers and a Tier1 transit provider. Not many non-research networks to be seen.
Also, since we didn't use it it kept breaking and I had to fix it every two years or so, where it probably had been down for months.
I don't believe in Internet-wide multicast happening in current incarnation, it's just too fragile and too few people are using it. It wouldn't scale either due to all the state that needs to be kept.
Inter-domain multicast was largely replaced in practice by CDN's. In addition to scale issues in keeping state, large wireless L1 environments are hostile to functioning multicast. Dale
I'll try to be brief-ish.. Interdomain Multicast suffered from three fundamental problems: 1) Deering's original use cases are far different from what it's used for today. His original intent was to create a broadcast domain overlay over an L3 topology. With this came reqs which today are largely nothing more than unnecessary complexity with limited security and stability. The primary bit of baggage is network based source discovery - the idea that anyone can send and everyone will get those packets. Today all we want are explicit trees. SSM solves these issues, but requires IP stacks, apps, and networks to all support SSM. BUT, the one bit that Deering got right which the community ditched was overlay. He knew not all boxes would support it so DVMRP included tunneling (which I think is the first RFC to use overlay encapsulation, but I'm willing to be wrong here.) When PIM replaced DVMRP we unfortunately retained network based source discovery (RPs, MSDP, etc..) but ditched encapsulation. This caused number 2 below. 2) Everyone must enable it or nobody can really benefit from it. The push for native multicast (PIM) at the end of the last century was well intended, but failed. If we had made IGMP multi-hop or something similar to provide jumping over unicast-only networks we may be in a different place today. But today we do have AMT which is trying to solve this problem. Some venders do support it and some networks have already rolled it out in trials. This may have some hope in changing the game. 3) Multicast is UDP. Many of the "multicast" problems people have stated here on the list can more accurately be classified as UDP problems. When using UDP rather than TCP, congestion control and reliability need to be addressed at the application layer. Some solutions have capitalized on this requirement by engineering solutions for each independently rather than being stuck trying to game TCP (see unicast ABR). So, with SSM only, an overlay layer like AMT, and a resilient application layer CC and reliability we may have the right tools to see a larger global multicast footprint. Or we may have figured all this out a bit too late. Greg On Tue, Sep 2, 2014 at 9:48 AM, Dale W. Carder <dwcarder@wisc.edu> wrote:
Thus spake Mikael Abrahamsson (swmike@swm.pp.se) on Tue, Sep 02, 2014 at 06:05:42PM +0200:
On Tue, 2 Sep 2014, Octavio Alvarez wrote:
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
I have set up interdomain routing connecting both to a few peers and a Tier1 transit provider. Not many non-research networks to be seen.
Also, since we didn't use it it kept breaking and I had to fix it every two years or so, where it probably had been down for months.
I don't believe in Internet-wide multicast happening in current incarnation, it's just too fragile and too few people are using it. It wouldn't scale either due to all the state that needs to be kept.
Inter-domain multicast was largely replaced in practice by CDN's.
In addition to scale issues in keeping state, large wireless L1 environments are hostile to functioning multicast.
Dale
Le 02/09/2014 18:05, Mikael Abrahamsson a écrit :
On Tue, 2 Sep 2014, Octavio Alvarez wrote:
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
I have set up interdomain routing connecting both to a few peers and a Tier1 transit provider. Not many non-research networks to be seen.
Also, since we didn't use it it kept breaking and I had to fix it every two years or so, where it probably had been down for months.
I don't believe in Internet-wide multicast happening in current incarnation, it's just too fragile and too few people are using it. It wouldn't scale either due to all the state that needs to be kept.
Been there as well. Now, IPv6 mcast? ;-) Cheers, mh
On Tue, 02 Sep 2014 08:43:16 -0700 Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
No not all and even those that do often do not do so on the same gear, links and peers as their unicast forwarding.
Why would that be, are network devices not able to support multicast?
That was part of it, but there is also some benefit to separating it. When I ran networks with it, we essentially had it everywhere so I'm not the best person to explain the reasons others may have had. IP multicast can be difficult to troubleshoot and maintain, especially when it often runs for months on end without issue, until it doesn't. There may be practical scaling limitations and security issues. So isolation in part may be both a practical necessity and an operational safeguard.
I have never used interdomain multicast but I imagine the global m-routing table would quickly become large.
The routes wouldn't need to look much different than unicast, but when you have to start maintaining other state other than just route reachability, particularly for tracking participants in groups and sources, things can get unwieldy fast. The best thing I can say about IP multicast is that it nice experience to *have had*. Note, this is not to disparage decisions by those who choose to use IP multicast for certain circumstances, which is still in widespread use and successful such as with TV over cable networks, but those are largely isolated environments and configurations are generally set in such a way that much of the scaling, state and security issues are sufficiently dealt with. John
participants (12)
-
Corey Touchet -
Dale W. Carder -
Greg Shepherd -
Jeff Tantsura -
John Kristoff -
Justin M. Streiner -
Michael Hallgren -
Mikael Abrahamsson -
Octavio Alvarez -
S, Somasundaram (Somasundaram) -
William F. Maton Sotomayor -
William Herrin