8 ms·

I spent a decade working on multicast, helped write some of the second generation multicast conferencing tools, and co-authored a number of the standards. Gene

I spent a decade working on multicast, helped write some of the second generation multicast conferencing tools, and co-authored a number of the standards. Generally, the issue was that multicast requires per group or per-source state in routers, and router memory was a scarce resource. This made it hard to scale globally. It also made forwarding problems hard to diagnose, taking up operators' time. These costs, plus an unclear connection between who benefitted from multicast and who paid for it made it difficult for core ISPs to justify. And that meant that commericial content or application providers needed to implement a plan B in case multicast wasn't available, and if that worked well enough, they didn't bother with also doing multicast. Still, RTP and SIP came directly out of the MBone, and they bootstrapped the whole Internet multimedia phenomena we're all enjoying today while working from home.

q3k 7y ago
I wouldn't exactly say I 'enjoy' using SIP.
- mhandley 7y ago
  Sorry about that! It did rather morph from our nice simple initial design into a monster once it met the real world.
  - organsnyder 7y ago
    As everything is wont to do.
- jimmySixDOF 7y ago
  Well it sure beat using H.323
- zajio1am 7y ago
  While it has some wrinkles, i must say that i have generally much better experience with SIP tools than with a current wave of WebRTC tools.
- wolrah 7y ago
  Why not? Personally I enjoy SIP itself greatly, it works well and is basically human readable, to the point that I can explain it to non-technical people. My main problems over 15 years of working with SIP have been with "helpful" boxes in the middle tampering with my SIP messaging. NAT used to cause a bunch of problems, but these days I have workarounds for most cases that work great until the aforementioned middleboxes start "helping". Give me a NAT-free network where the packet that reaches the far end is the same one I sent and my SIP systems will be quite happy.
the8472 7y ago
The downside is that CDNs are far less democratic than hypothetical end-to-end multicast support. Imagine being able to stream to thousands of users from a single machine with a single 100Mbit NIC.
- corrigible 7y ago
  Wouldn't torrents sort of help with that? (I guess only once a couple of peers are present...)
  - the8472 7y ago
    Torrents don't work well with mobile devices, multicast could be implemented more efficiently at the physical layer of a shared medium. Torrents also have higher latency and you're at the mercy of the aggregate upload bandwidth of the swarm. On a good day they can be good enough for VoD style streaming but that's far from assured unless the distributor at least keeps some backup bandwidth ready if demand exceeds supply (which sounds a bit like a CDN). For realtime streaming IP-multicast would still be the ideal solution.
    - namibj 7y ago
      Well, https://www.bittorrent.org/beps/bep_0014.html https://www.bittorrent.org/beps/bep_0014.html isn't even that new, and yeah, it's only for service discovery right now, but I'm pretty sure you'd get multicast support in the popular clients, at least for Merkle-Tree (BEP-0030) torrents with e.g. 2^10 piece size.
      - the8472 7y ago
        BEP14 is totally irrelevant to the discussion here. It's only for finding peers in a local lan, not for distributing payload via multicast. The latter is and always has been via unicast.
kingosticks 7y ago
I would just add that router memory is still pretty scarce and assigning more of it to multicast state is not going to win you any more sales. A bit of a chicken and egg problem there with regards to trying to use it at scale.
- the8472 7y ago
  > A bit of a chicken and egg problem there A best-effort multicast approach would help here. Reach as many endpoints as you can utilizing otherwise-unused router memory for the group memberships then bridge the gaps created by saturated routers via unicast relays.
  - kingosticks 7y ago
    > otherwise-unused router memory This makes it sound like a dynamic pool of memory which can be allocated for different purposes. I was talking about an ASIC where the amount of available memory for these state tables might be fixed and not available for sharing with other parts of the system. You get whatever the designers back in 2015 decided was needed and the point is there's not much reason for them to spend area implementing a bigger memory when the reality today is that it's hardly used. So I get what you are saying but it's not necessarily possible.
    - the8472 7y ago
      It is a bit of a hypothetical scenario. The assumption is that the router is already capable of multicast routing in the first place (e.g. whatever ISPs are using to forward their IPTV) and have some spare capacity for future growth in those multicast routing tables that could be used to enable best-effort forwarding.

q3k 7y ago

I wouldn't exactly say I 'enjoy' using SIP.

mhandley 7y ago
Sorry about that! It did rather morph from our nice simple initial design into a monster once it met the real world.
- organsnyder 7y ago
  As everything is wont to do.
jimmySixDOF 7y ago
Well it sure beat using H.323
zajio1am 7y ago
While it has some wrinkles, i must say that i have generally much better experience with SIP tools than with a current wave of WebRTC tools.
wolrah 7y ago
Why not? Personally I enjoy SIP itself greatly, it works well and is basically human readable, to the point that I can explain it to non-technical people. My main problems over 15 years of working with SIP have been with "helpful" boxes in the middle tampering with my SIP messaging. NAT used to cause a bunch of problems, but these days I have workarounds for most cases that work great until the aforementioned middleboxes start "helping". Give me a NAT-free network where the packet that reaches the far end is the same one I sent and my SIP systems will be quite happy.

the8472 7y ago

The downside is that CDNs are far less democratic than hypothetical end-to-end multicast support. Imagine being able to stream to thousands of users from a single machine with a single 100Mbit NIC.

corrigible 7y ago
Wouldn't torrents sort of help with that? (I guess only once a couple of peers are present...)
- the8472 7y ago
  Torrents don't work well with mobile devices, multicast could be implemented more efficiently at the physical layer of a shared medium. Torrents also have higher latency and you're at the mercy of the aggregate upload bandwidth of the swarm. On a good day they can be good enough for VoD style streaming but that's far from assured unless the distributor at least keeps some backup bandwidth ready if demand exceeds supply (which sounds a bit like a CDN). For realtime streaming IP-multicast would still be the ideal solution.
  - namibj 7y ago
    Well, https://www.bittorrent.org/beps/bep_0014.html https://www.bittorrent.org/beps/bep_0014.html isn't even that new, and yeah, it's only for service discovery right now, but I'm pretty sure you'd get multicast support in the popular clients, at least for Merkle-Tree (BEP-0030) torrents with e.g. 2^10 piece size.
    - the8472 7y ago
      BEP14 is totally irrelevant to the discussion here. It's only for finding peers in a local lan, not for distributing payload via multicast. The latter is and always has been via unicast.

kingosticks 7y ago

I would just add that router memory is still pretty scarce and assigning more of it to multicast state is not going to win you any more sales. A bit of a chicken and egg problem there with regards to trying to use it at scale.

the8472 7y ago
> A bit of a chicken and egg problem there A best-effort multicast approach would help here. Reach as many endpoints as you can utilizing otherwise-unused router memory for the group memberships then bridge the gaps created by saturated routers via unicast relays.
- kingosticks 7y ago
  > otherwise-unused router memory This makes it sound like a dynamic pool of memory which can be allocated for different purposes. I was talking about an ASIC where the amount of available memory for these state tables might be fixed and not available for sharing with other parts of the system. You get whatever the designers back in 2015 decided was needed and the point is there's not much reason for them to spend area implementing a bigger memory when the reality today is that it's hardly used. So I get what you are saying but it's not necessarily possible.
  - the8472 7y ago
    It is a bit of a hypothetical scenario. The assumption is that the router is already capable of multicast routing in the first place (e.g. whatever ISPs are using to forward their IPTV) and have some spare capacity for future growth in those multicast routing tables that could be used to enable best-effort forwarding.