Re: Confirming source-routed multicast is dead on the public Internet
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. etc. 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. Regards, Jakob. -----Original Message----- Date: Wed, 1 Aug 2018 19:24:21 +0300 From: Saku Ytti <saku@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 supported.
Hey, On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG <nanog@nanog.org> wrote:
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. etc. 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.
Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :) -- ++ytti
On Fri, 3 Aug 2018 at 00:42, Saku Ytti <saku@ytti.fi> wrote:
Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :)
I may have worded up-speed potentially ambiguously, I mean over-speed, meaning access needs higher than stream bitrate to receive stream of specific bitrate. In practical world, of course already very problematic scenario for most NFLX consumers. -- ++ytti
You could put this multicast receiver into the last hop before the customer and then send unicast to the customer. Regards, Jakob. -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Thursday, August 2, 2018 2:45 PM To: Jakob Heitz (jheitz) <jheitz@cisco.com> Cc: nanog@nanog.org Subject: Re: Confirming source-routed multicast is dead on the public Internet On Fri, 3 Aug 2018 at 00:42, Saku Ytti <saku@ytti.fi> wrote:
Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :)
I may have worded up-speed potentially ambiguously, I mean over-speed, meaning access needs higher than stream bitrate to receive stream of specific bitrate. In practical world, of course already very problematic scenario for most NFLX consumers. -- ++ytti
ok. Play 2 minutes of ads at the start and save a stream. Play another 2 minutes of ads every 16 minutes, then the maximum number of streams is 4. The ads can be received in a single stream or be received after the shorter streams have completed. Regards, Jakob. -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: Thursday, August 2, 2018 2:42 PM To: Jakob Heitz (jheitz) <jheitz@cisco.com> Cc: nanog@nanog.org Subject: Re: Confirming source-routed multicast is dead on the public Internet Hey, On Fri, 3 Aug 2018 at 00:36, Jakob Heitz (jheitz) via NANOG <nanog@nanog.org> wrote:
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. etc. 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.
Cute :). Well 8*bitrates, but nice optimisation to make stream count finite. Of course at cost of quality, as receiver needs up-speed of 8x at start. Interesting side-effect, quality increases as movie progresses :) -- ++ytti
participants (2)
-
Jakob Heitz (jheitz) -
Saku Ytti