Confirming source-routed multicast is dead on the public Internet
Jakob Heitz (jheitz)
jheitz at cisco.com
Thu Aug 2 21:33:33 UTC 2018
Hey, there's a better way.
Split the movie into segments:
Segment 1: Minute 1.
Segment 2: Minute 2.
Segment 3: Minutes 3,4.
Segment 4: Minutes 5-8.
Segment 5: Minutes 9-16.
Then send each segment in a loop.
Each receiver receives every loop simultaneously.
Each segment may start receiving part way through, but then it starts again.
By the time a segment needs to play, it is completely received.
A 128 minute movie needs 8 streams.
While waiting for the first minute, you can play ads :)
The shorter segments don't need to be sent for long:
Receivers can stop receiving the short segments once they have received one loop of it.
When no receiver is receiving a loop, you can stop sending it.
Date: Wed, 1 Aug 2018 19:24:21 +0300
From: Saku Ytti <saku at ytti.fi>
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
More information about the NANOG