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)?
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
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.
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
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
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.
> 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
Thus spake Mikael Abrahamsson (swmike@swm.pp.se) on Tue, Sep 02, 2014 at 06:05:42PM +0200:
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
Ditto, although business needs played a part as well. 
wfms
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
Le 02/09/2014 18:05, Mikael Abrahamsson a �crit :