[opendtv] Re: IPTV on AP: Interactive TV Poised for a Rollout (Feb 13)
- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
- To: "OpenDTV (E-mail)" <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 16 Feb 2005 13:49:40 -0500
> > If response is faster with IPTV, it must mean that
> > the IP multicasts are flowing throughout the IPTV
> > network all the time. Because you can easily
> > expect similar delays for IP multicast, if you
> > expect to be building and pruning multicast trees
> > as users "tune" in and out. Therefore, in practice,
> > the bandwidth is not really being managed all that
> > differently. The core of the IPTV net will be
> > loaded with TV streams, much as cable nets are with
> > their fixed 6 MHz bands.
Craig Birkmaier wrote:
>
> VOD is not "typically an IP multicast service.
Yes, true, unless it's NVOD. I was really describing
the situation with live multicast streams, when IPTV
subscribers flip between channels.
> You can route everything from the central
> office/head end, in which case the network will
> only contain packets being routed to specific STBs.
> Or, you can place routers close to the home and
> deliver the most popular multicasts out to the edge,
> preserving "trunk" bandwidth.
The content needs to get to those servers close to the
edge, which takes up trunk bandwidth. But certainly,
for VOD, that's the way to go. Or hey, better yet,
why not locate the storage on the customer premises?
That's the tradeoff. With cable, while the network
can in principle install a distributed set of servers
for better VOD (and migrate that to IP), this isn't
mandatory. The PVR function can be owned or rented by
subscribers. With IPTV, instead, it's more appropriate
that the network incorporate those servers, because
the drop cable to each subscriber is not very wide. To
me, that's not a slam dunk advantage of IPTV. It's
more like a work-around.
However, *if* service providers prefer to incorporate
their own PVRs within the network, because it
provides them with more revenue, then you might
conclude that the IPTV last drop bandwidth constraint
is not a problem. To the provider, might not be. But
to the consumer?
> with MP{EG-2 TS based system you can waste
> considerable bandwidth padding out the substreams
> within a 6 MHz channel (although stat muxing of the
> streams helps to maximize the utilization of each 6
> MHz channel.
Remember that with 256-QAM, you get 38.8 Mb/s out of
each 6 MHz channel. That gives you plenty of bandwidth
for doing efficient stat mux, much as an Ethernet
link would do. And of course, DOCSIS puts IP traffic
over these 6 MHz channels, so you can do anything
permitted by RTP/RTCP just as well over MPEG-2 TS as
you can over Ethernet. Including resynchronizing
multiple incoming streams into one output stream.
The differences are just not so big. Not if cable and
IPTV systems are each configured as well as they can
be.
> They are very different. IP multicasts are a SOURCE
> for the routers in an IPTV system. The viewer
> chooses to join a multicast, which is then routed to
> that home. How far the multicast is carried through
> the system infrastructure is just a question of
> system design.
Yes, that last sentence glosses over what I've been
talking about.
Imagine a market full of couch potatoes flipping
between live channels. Each subscriber conducts IGMP
with the edge router of the IPTV net.
If you go for bandwidth efficiency, the edge router
would then conduct a multicast routing protocol to
request or drop membership to these multicast groups
from the network core. But these protocols don't react
instantaneously. They can't. So typically, if group
membership is dropped by all IGMP hosts in a given
subnet, the edge router will continue to receive the
multicast packets of that multicast group from the
core, for a period of minutes. Until that tree branch
is pruned.
This means that as subscribers flip channels, the core
is becoming saturated with multicast streams. They
aren't being dropped instantaneously, even if no one
is watching *right now*.
Also, if you take the max efficiency strategy, a
subscriber joining a multicast first within a given
subnet will have to wait for the network to graft this
new branch onto an existing multicast tree, or might
even have to reach as far back as the source edge
router to start a new tree. This can easily take 20
or 30 seconds, depending on the size of the network
and on how much background traffic (overhead) the
network admin is allowing for multicast routing
protocols. The faster the response, the more the
overhead.
So in practice, because of the two effects described
above, IPTV systems don't shoot for super bandwidth
efficiency. They compromise for a better viewer
experience. The live multicast streams take up core
bandwidth, so there is no real possibility for
infinite channel selection, or anything remnotely
resembling that.
For VOD, you have the problem of network saturation,
just as any unicast streaming media network has.
Location of servers close to the edge helps, but it
adds cost too. And again, servers have limits, so
there is no possibility of infinite channel
selection, or anything close to that.
So in practice, no big difference.
Bert
----------------------------------------------------------------------
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:
