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