Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 22 Dec 2011 23:12:20 +0000

Hi Sue,

I think it really depends whom you speak to. Buffering can be done in
different places (e.g., broadcast stations put 5 sec delay in their live
streams). This requirement alone won't require unicast streaming.

Cheers,
Yiu

On 12/22/11 6:07 PM, "Susan Hares" <[email-masked]> wrote:

> Yiu Lee:
>
>Many people who I asked about live feeds, said the live feeds were often
>shifted 5-20 minutes and then done as normal video streaming.
>
>Is this true? 
>
>Thanks, and If I don't hear from you.. Merry Christmas,
>
>Sue 
>
>-----Original Message-----
>From: Tina TSOU 
>Sent: Thursday, December 22, 2011 6:05 PM
>To: Lee, Yiu; [email-masked]; [email-masked]
>Subject: RE: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP
>
>Yiu,
>You address my puzzle. Thanks and Merry X'mas!
>
>
>Best Regards,
>Tina TSOU
>http://tinatsou.weebly.com/contact.html
>
>
>-----Original Message-----
>From: Lee, Yiu [mailto:[email-masked]]
>Sent: Thursday, December 22, 2011 2:50 PM
>To: Tina TSOU; [email-masked]; [email-masked]
>Subject: Re: [MBONED] Carriers' IPTV uses multicast vs unicast, OTT/HTTP
>
>For OTT providers, unicast is the current option to deliver live content
>because inter-domain multicast is uncommon. Speaking of trend, using
>unicast for broadcasting is inefficient IMHO, so I don't see why using
>http to deliver live content is the trend.
>
>My 2 cents.
>
>
>On 12/22/11 2:52 AM, "Tina TSOU" <[email-masked]> wrote:
>
>>Hi,
>>Someone mentioned that it seems the trend that carriers' IPTV uses
>>unicast, OTT/HTTP, rather than multicast.
>>Thoughts?
>>
>>Sent from my iPad
>>_______________________________________________
>>MBONED mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/mboned
>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 22 Dec 2011 23:20:59 +0000

AFAIK, the major push to use multicast is to preserve bandwidth. I don't
see how buffering would make multicast even more favorable. If so, I would
like to know why.

On 12/22/11 6:16 PM, "Susan Hares" <[email-masked]> wrote:

> Yiu:
>
>Wow! Thanks for the quick response. I was a bit unclear.
>
>My understanding is that the buffering actually pushes things toward the
>multicast model.
>
>Sue 
>
>Sent: Thursday, December 22, 2011 6:12 PM
>To: Susan Hares; Tina TSOU; [email-masked]; [email-masked]
>>Many people who I asked about live feeds, said the live feeds were
>>often shifted 5-20 minutes and then done as normal video streaming.
>>
>>Is this true? 
>>
>>For OTT providers, unicast is the current option to deliver live
>>content because inter-domain multicast is uncommon. Speaking of trend,
>>using unicast for broadcasting is inefficient IMHO, so I don't see why
>>using http to deliver live content is the trend.
>>
>>My 2 cents.
>>
>>

---

From: "Lee, Yiu" <[email-masked]>
Date: Thu, 22 Dec 2011 23:27:32 +0000

Hi Sue,

The buffering is happening today. But a carrier can still use unicast if
she likes to. The buffering should not make a difference for the delivery
method. Am I missing anything?

Cheers,
Yiu

On 12/22/11 6:22 PM, "Susan Hares" <[email-masked]> wrote:

>Yiu:
>
>My understanding is that the buffering of the live event is at the source
>- just like a video would be recorded. The actual deliver uses the
>multicast infrastructure to be efficient.
>
>Am I clearer this time?  Maybe I need to drink more coffee.
>
>Cheers,
>
>Sue  
>
>Sent: Thursday, December 22, 2011 6:21 PM
>see how buffering would make multicast even more favorable. If so, I
>would like to know why.
>
>
>>My understanding is that the buffering actually pushes things toward
>>the multicast model.
>>
>>Sue
>>
>>different places (e.g., broadcast stations put 5 sec delay in their
>>live streams). This requirement alone won't require unicast streaming.
>>
>>Cheers,
>>Yiu
>>
>>