Kyle Rose wrote:
Unicast delivery is very mature in every way: not just reliable transport, but operations, monitoring, congestion control, authentication, and confidentiality.
Congestion control for multicast is just impossible (what if, a new user with a 64Kbps link joins a group when 1M users are enjoying to receive 1Mbps traffic). As such, speed must be determined by sender side, which can not be TCP friendly. So, multicast in WAN can be practical only with QoS guarantee with usage based charging. In an ISP, it is not so difficult to manually prioritize some multicast traffic with advance agreements between the ISP and multicast senders.
it's the rest of the ecosystem that requires a large lift to get multicast delivery to the point where it is viable for businesses whose users have high baseline quality expectations.
With best effort, flat rated Internet, end users are not motivated to be multicast capable and content providers just use parallel unicast servers. With QoS guaranteed, usage based charging Internet, paid charge can be reduced by multicast, which will be the economic incentive to deploy multicast. A problem is that best effort speed of the Internet today is fast enough for most purposes. But, 8K video streaming can be a candidate. > In > most cases, technologies for doing those things don't exist except on > paper, and even then have not been battle-tested by operators for 40 > years. While I designed and implemented fully automated QoS/multicast signaling protocol with BW and charge based QoS routing, as a starter, fully manual prioritization is trivially easy with commercially available technologies. Masataka Ohta
