[opendtv] Re: Internet TV distribution architecture
- From: Kon Wilms <konfoo@xxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Sat, 11 Jan 2014 08:54:50 -0800
On Fri, Jan 10, 2014 at 9:58 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx>wrote:
> Glad to see you are still around.
>
Yes, finally decided to stop working for the man and do only consulting :-)
> IF they are limited to “broadcasting” then they would only need to deliver
> the stream for each sub channel to each ISP, as they do today with direct
> feeds to many MVPDs (as opposed to the MVPD pulling these bits out of the
> air.
>
Well, there are tens of thousands of ISPs. In many cases a single
datacenter may house a number of ISPs. And a single ISP may be in multiple
geographic locations in branches that don't even communicate with each
other. So you're back to using a CDN/Network.
> Are you saying that a single stream per “channel” delivered to the ISP
> would not work? If there are issues within the ISP network, would it not be
> the ISPs problem to deal with this? Differences in latency within the ISP
> network would seem to be minimal as long as the buffers at each customer
> are kept full. I don’t think that every customer needs to receive the same
> bits at the same time.
>
I'm saying it may prove such a drain on rollout, deployment and management
of the network as to render the effort unprofitable. If you used fragmented
MP4 you could at least get over some of the hurdles with buffering and
latency at the expense of every viewer having their live stream delayed
between a minimum of 30 seconds and max of say 1.5 minutes.
Also, you're not going to have multicast support unless you implement an
overlay network to each ISP, or tunnel the UDP through TCP. And for the
latter, you're going to need equipment to terminate those streams and emit
them on the ISP network. So you're doing a rollout of at least a half rack
of gear regardless.
Probably the best option is to pick large datacenters in each major city
(Tier4 with blended bandwidth, carrier connectivity that is only 1-2 hops
from your install, and hooks into multiple if not all ISPs for the local
area i.e. TWC/Cox/etc), deploy a half rack of gear to each one of those,
and push streams to those hubs from a central location (or even over
satellite where possible).
From there you could build out that small footprint to IP multicast if
supported, or add more gear for caching to provide streams as HTTP where
multicast is not available.
Cheers
Kon
> On Jan 10, 2014, at 11:07 AM, Kon Wilms <konfoo@xxxxxxxxx> wrote:
>
> On Fri, Jan 10, 2014 at 7:30 AM, Craig Birkmaier <craig@xxxxxxxxxxxxx>wrote:
>
>> > On Jan 9, 2014, at 7:52 PM, "Manfredi, Albert E" <
>> albert.e.manfredi@xxxxxxxxxx> wrote:
>>
>
>
>> Why would they need any servers. To replicate their existing business
>> model, all they need is one IP Multicast stream per market (or several if
>> they are multicasting today). Why would the networks let the local
>> broadcasters stream the network feeds AND Offer this content as VOD streams?
>>
>
> Given the fact that every group of subs may have a unique routing path,
> you still have to troubleshoot issues with latency. Bandwidth is no longer
> the issue, but good luck troubleshooting all those hops and fixing latency
> issues out of your control. The only option would be to put edge servers in
> local pops with guaranteed bandwidth, push streams to them possibly over
> some sort of fixed path/tunnel, and make that available via IP multicast.
>
> Current CDNs aren't built for this model. They are most if not all based
> on TCP/HTTP pull.
>
> Plus there is the problem that CDNs share traffic and use infrastructure
> you don't control. The only way to be profitable is to over-provision the
> network. You have no guarantee that a edge node will be able to fulfill
> your content delivery requirements (bandwidth/cpu/storage) if some other
> customers have a huge traffic spike. The larger CDNs just have more boxes
> in the field. But hardware ages quickly these days, so even that becomes an
> issue with failure rates and cost of maintenance. And last if you use a CDN
> you don't get to determine the path traffic flows through it, so you have
> to design and tweak your system around this black box router that may have
> dozens of exceptions to every rule that are out of your control.
>
> For the type of delivery we are talking about, only way to do it is to
> build the CDN yourself.
>
> Cheers
> Kon
>
>
>
Other related posts: