Hey Miles and Michael, It is entirely fair to debate what the use-case would be, the underlaying technical problem remains the same, if it becomes useful (globally) we don't have the hardware to cater for it. I'm sure both of your use cases are used extensively in internal network. I've worked for company who distributed broadcast TV on their MPLS IP backbone, two-plane network, red and blue, one copy for each tv channel on both planes and far-end drops redundant copy. Very attractive solution commercially for client and provider. But no potential for global scale. On Wed, 1 Aug 2018 at 20:44, Miles Fidelman <mfidelman@meetinghouse.net> wrote:
On 8/1/18 12:24 PM, Saku Ytti wrote:
Hey Mankamana,
other than billing problem, is there any other reasons why multicast would not be viable for public internet ? Imagine someone like youtube or netflix would like to use multicast, instead of caches. They'd need to start new multicast stream for every content with small delay (to get more viewers on given stream), how much delay would consumer tolerate before content starts? 1min? 5min? So every minute or every 5 minute new stream of movie would be sent, except it would need to be sent many times, for each bitrate supported. Each of these streams is wide (wider than unicast) HW state that needs to be stored on every device on path, for unicast we only store 1 narrow HW state per destination, for multicast we store 1 wide HW state per flow/stream, we don't have the hardware to do that, if there would be any significant demand for multicast. It only works when there is no use-case for it, and even then, it's insecure DoS vector.
Personally, I think the use case is a lot stronger for multi-person video conferencing.
Miles Fidelman
-- In theory, there is no difference between theory and practice. In practice, there is. .... Yogi Berra
-- ++ytti