[opendtv] Re: Internet TV distribution architecture
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Tue, 7 Jan 2014 11:28:16 -0500
On Jan 6, 2014, at 4:52 PM, "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
wrote:
>
> Craig Birkmaier wrote:
>
>>> Pay attention, Craig. Where exactly do you think Akamai's mirrored
>>> servers are physically located, with respect to individual ISP
>>> networks?
>
>> Exactly where I stated yesterday.
>
> The question is specific. With respect to ISP networks, you know, those
> networks that actually connect individual homes, where are the mirrored
> servers located? Within? Outside? A different city?
YES. All of the above.
Co siting within ISPs is not widespread, however, it all comes down to where
the WAN hubs are located, and the size of the mirror server installation. In
some cases it may make more sense to pay for co-location at the hub; in other
cases it may be asleep rate facility that has big pipes to the hub. As the big
telcos operate a big chunk of the backbone WANs, they have become a major
player in the CDN business as well.
How many servers, and where they are located is not the important question -
the investment will be made where the demand warrants, and facilities will
scale up as demand increases. Adding the bandwidth to the lady mile is still
the most expensive proposition, an area where the cable companies have a
considerable advantage.
>
> Now, add to the ISP network a heavy demand for TV content. In bigger cities,
> demand in the hundreds of thousands of sessions during prime time or during
> popular games, within that ISP's local network in that city. This is new
> demand, not currently handled by anyone. Will those new streams originate at
> existing mirrored servers? Or will more be required?
Both. And remember, for a large portion of viewers, IP Multicast can deal with
the demand issues...
Especially for "live" versus VOD streams.
>
> Like I said, if you completely ignore bandwidth considerations, a single
> server is limited to 64K sessions (65536 - 1024 "well known ports," minus
> other registered ports in theory anyway, so actually less than 64,000). So,
> let's pretend 64,000 sessions. If a server is managing 64,000 HDTV sessions,
> each one average, say, 6 Mb/s, that one server would be transmitting a
> whopping 384 Gb/s. Do you think that's sensible to expect from one server?
>
> And that's just the first 64K households. I doubt that whoever is managing
> the mirrored servers for a major city will be able to get by without adding
> plenty of server capacity to what they have today, to accommodate heavy
> demand for TV sites. The only question is who jump at the opportunity for
> this new TV traffic?
The same companies that are doing it now. This is all about scale. Until every
home has a broadband pipe with at least 10 - 20 Mbps bandwidth, the larger
problem will remain the last mile
>
>> Clearly, LTE broadcast makes sense for local broadcasters...
>
> Not clearly at all. We went through all of that in depth two years ago.
> Perhaps broadcasters can piggyback on existing WISP networks. I very much
> doubt the broadcasters would deploy their own thick mesh of transmitters for
> their own LTE infrastructure, to achieve anything similar to the b/s/Hz they
> get today, and I very much doubt the WISPs in the US would sell smartphones
> with those broadcaster-unique frequencies on them. But sure, piggy-back on
> WISP nets, and the WISPs will see $ signs.
>
> The reason you need a thick mesh is because the spectral efficiency of LTE
> broadcast mode is tied to spacing between towers. No arm-waving on this,
> please.
>
We disagree. For Broadcast LTE the mesh does not need to be as dense as you
assert.
Regards
Craig
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts: