3 ms·
> There's a lot of network infrastructure that could be improved by them. One killer feature was multicast streaming of data. The streaming could do an extra
by bb88 2y ago
> There's a lot of network infrastructure that could be improved by them.
One killer feature was multicast streaming of data. The streaming could do an extra 5% of broadcasting packets instead of several round trips and retransmissions.
Now that I think about it, I wish we actually used multicast.
- ddingus 2y agoMe too. SGI had good support for it in IRIX and I am pretty sure I saw one video streaming solution using it on a LAN to maximize the throughput possible. Seems like a good tech that fell into disuse.
- vermilingua 2y agoIP CCTV and IP TV (think hotels) make extensive use of multicast, it's not completely disused; but only practical on LAN.
- ddingus 2y agoGood to know. That was basically the use case for it back in the day too. Multiple video streams.
- zamadatix 2y agoThe hard part about multicast is the scaling overhead of coordinating which streams should go where when it's more than "these couple things on these couple networks". Even then, the way it's a dedicated range of IPs instead of parts of public assignments pretty much shut down the idea it could ever be coordinated at scale outside of a few private networks doing it together. It has found good success in IPTV delivery inside provider's own networks though. Cameras at casinos/hotels/Transit systems and the like too.
- xxpor 2y agoCopying packets is brutal in software as well.
- zamadatix 2y agoPushing packets in software is generally brutal but multicast/broadcast should be inherently easier. It's less "copy this packet 27 times" and more "instead of receiving 27 packets and sending 27 packets you receive 1 packet and send it 27 times before you remove it from memory". The "hard" part becomes dealing with the queues filling up because you're inherently able to churn out so much more data than you're able to receive vs unicast.
- elcritch 2y agoIpv6 works much better with multicast. I learned about it a few years back and it's actually core to the ipv6 protocol. That means all ipv6 routers must support multicast. There's 2^112 possible global multicast addresses with ipv6 as well (1). Though yeah, you'll still have queuing overloads as well and other issues. 1. https://learningnetwork.cisco.com/s/question/0D53i00000Kt0EKCAZ/ipv6-multicast-address-ccna https://learningnetwork.cisco.com/s/question/0D53i00000Kt0EK...
- wmf 2y agoall ipv6 routers must support multicast That doesn't help if all routers have it turned off.
- zamadatix 2y agoI'm a big IP v6 fan but the multicast improvements are oft overstated. The meat and potatoes changes are about getting rid of broadcasts in a LAN (in a way where a dumb switch will still treat them as broadcast anyways), not about actual routing of multicast between LANs. There is no requirement IPv6 routers must support routing multicast outside of the LAN (a completely different task). There is no public assignment of ff00::/8, it's still a free for all for generic streams. There's nothing that makes routing it across LANs easier to scale and orchestrate (in fact the protocols for this are separate from IP anyways). Effectively, the only real "improvement" for the routed multicast case is you have more private multicast addresses to pick from.
- elcritch 2y agoYeah, it’s unfortunate multicast outside your own LAN isn’t more well supported. It makes sense as it’d require more orchestration above IP. Though I’d argue that 112 bits of random addresses makes the need for global registration largely unnecessary. Similarly to the rest of IPv6, the address is intentionally so large that it allows random IP generation with very low collision probability.
- zamadatix 2y agoGlobal registration is more about "a way to orchestrate who's allowed to send data to the ff00::1234 group" than "I hope we don't accidentally overlap!". It's the same reason we assign IPv6 unicast space to entities even though random generation could work almost all of the time.