Zebroid: Using IPTV Data to Support Peer-Assisted VoD
Content Delivery
Yih-Farn Robin Chen, Rittwik Jana,
Daniel Stern, Bin Wei, Mike Yang
AT&T Labs - Research
Florham Park, NJ, 07932
chen,rjana,dstern,bw,yang@research.att.com
Hailong Sun
School of Computer Science and Engineering
Beihang University, Beijing
sunhl@act.buaa.edu.cn
ABSTRACT
P2P file transfers and streaming have already seen a tremen-
dous growth in Internet applications. With the rapid growth
of IPTV, the need to efficiently disseminate large volumes of
Video-on-Demand (VoD) content has prompted IPTV ser-
vice providers to consider peer-assisted VoD content deliv-
ery. This paper describes Zebroid, a VoD solution that uses
IPTV operational data on an on-going basis to determine
how to pre-position popular content in customer set-top
boxes during idle hours to allow these peers to assist the
VoD server in content delivery during peak hours. Latest
VoD request distribution, set-top box availability, and ca-
pacity data on network components are all taken into con-
sideration in determining the parameters used in the striping
algorithm of Zebroid. We show both by simulation and emu-
lation on a realistic IPTV testbed that the VoD server load
can be significantly reduced by more than 50-80% during
peak hours by using Zebroid.
Categories and Subject Descriptors
H.4 [Information Systems Applications]: Communica-
tions Applications; H.5.1 [Multimedia Information Sys-
tems]: Video
General Terms
Algorithms, Design, Measurement, Performance
Keywords
Video-on-Demand, Peer-to-Peer, IPTV
1. INTRODUCTION
Video-On-Demand (VoD) services are being offered by
many IPTV service providers today. Peer to peer systems
(P2P) have become immensely successful for large scale con-
tent distribution on the Internet. Recently, peer-assisted
VoD delivery [6][8][1][9] has become an important research
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
NOSSDAV’09, June 3–5, 2009, Williamsburg, Virginia, USA
Copyright 2009 ACM 978-1-60558-433-1/09/06 ...$5.00.
topic due to its potential to help both IPTV service providers
and Internet video services offload the VoD servers dur-
ingbusyhours,increaseoverallnetworkdeliverycapacity,
and maximize profits with the existing infrastructure. Tra-
ditional P2P approaches such as BitTorrent[5] and Cool-
Streaming[12] use a tit-for-tat approach that is not needed
among set-top boxes in an IPTV neighborhood; the band-
width and storage of the peers can be reserved, either through
static allocation or dynamic allocation with proper incen-
tives, to assist the IPTV service providers to deliver VoD
content [7]. In addition, the default BitTorrent download
strategy is not well suited to the VoD environment because
it fetches pieces of the desired video, mostly out of order,
from other peers without considering when those pieces will
be needed by the media viewer.
Toast[4] corrects this problem by providing a simple ded-
icated streaming server and it favors downloading pieces of
content that will be needed by the media viewer sooner. One
potential problem with using Toast in a typical IPTV envi-
ronment is the low uplink bandwidth of peers - typically in
the order of 1-2 Mbps; in addition, it is desirable to allo-
cate only a small fraction of the peer’s upload bandwidth
for VoD delivery as the peer may need the rest of the up-
load bandwidth for other activities. This makes it difficult
to find enough peers to participate in the delivery of a re-
quested video with the aggregated bandwidth that meets
the video encoding rate (at least 6 Mbps for high-definition
(HD) content).
Push-to-Peer[11] and Zebra[2][3] go one step further by
proposing to pre-stripe popular VoD content on peer set-
top boxes (STB) during idle hours so that many peers will
be available to assist in the delivery of a popular video dur-
ing peak hours; however, both Push-to-Peer and Zebra only
used analysis and simulations without employing a real im-
plementation or using operational data to model their sys-
tems. This paper describes Zebroid, a peer-assisted VoD
scheme (and a successor to Zebra) that departs from previ-
ous approaches by using real IPTV operation data to esti-
mate content placement striping parameters based on video
popularity, peer availability and available bandwidth distri-
butions.
The contributions of this paper are in three areas:
• Use of IPTV operational data to estimate Zebroid pre-
population parameters.
• Design and implementation of a peer-assisted VoD sys-
tem that responds to typical residential network access
conditions and busy-hour VoD request patterns.
115

Figure 1: An IPTV architecture with FTTN access
• Emulations of Zebroid on a realistic IPTV testbed
based on traces from operational data.
2. IPTV ARCHITECTURE AND DATA
2.1 An IPTV Architecture
In [7], we described and analyzed a typical physical model
of FTTN (Fiber-to-the-node/neighborhood) access networks
for IPTV services. As shown in Figure 1, video streaming
servers are organized in two levels - a local video hub office
(VHO), which consists of a cluster of streaming servers or
proxies to serve viewers in a particular regional market, and
national super head end (SHE) offices, which can distribute
videos to local serving offices based on existing policies or on
demand. Each local VHO connects to a set of local central
offices (CO), and then to a set of access switches such as
DSL or FTTN switches called DSLAM, Digital Subscriber
Line Access Multiplexer, through optical fiber cables. Each
DSLAM switch connects a community of IPTV service cus-
tomers through twisted-pair copper wires. A community
consists of all homes which are connected to the same access
switch. The local video serving office (VHO) has a cluster
of video servers, which stream on-demand or live broadcast
videos to viewers, typically with a streaming bandwidth of
at least a few hundred Mbps.
We list important parameters based on this physical ar-
chitecture that would help the reader understand the design
behind the Zebroid algorithm:
• B
0D
: Download bandwidth into a home (typically 25-
50 Mbps). This bandwidth is shared by broadcast
channels (typically 2 HD and 2 SD channels through
multicast), VoIP, and High Speed Internet (HSI) ac-
cess.
• B
0U
: Upload bandwidth out of a home (typically 1-2
Mbps).
• B
1S
: Total capacity of the south-bound links (down-
links) of a local access switch. A typically FTTN
switch has 24 Gbps downlink switching capacity.
• B
1N
: Capacity of the north-bound link (uplink) of an
access switch to the service router in the CO. B
1N
is
typically 1 Gbps, but is upgradable.
• B
2S
: Link capacity from the CO to all the DSLAM’s
- typically in the order of 10 Gbps, but its actual
throughput is limited by the VoD server streaming ca-
pacity.
• N : Number of subscribers under each DSLAM (typi-
cally 96 or 192 subscriber homes).
• u: Average streaming bit rate of a video (typically 6
Mbps for HD and 2Mbps for SD).
Itwasobservedin[7]thatinordertoenableaP2Pcon-
tent delivery solution across communities, content needs to
be shared between customer residential gateways (RG) by
traversing up from one RG to the CO and routed back down
to another RG. This peering activity may result in a poten-
tial bottleneck in the DSLAM to CO link. The situation can
be alleviated by pre-populating content intelligently across
multiple STBs in a DSLAM community and allow these
peers to serve requesting peers from the same community;
however, to avoid traversing the uplink to the CO would re-
quire changes in the existing IPTV architecture to allow IP
routing through the DSLAM switch. Alternatively, if ample
cache storage is available at a DSLAM switch (not the case
today for a variety of engineering reasons), then even P2P
would not be needed.
2.2 IPTV Operational Data
In this section we analyze data from an operational service
to estimate pertinent Zebroid parameters like STB uptime
from power state data (PSD) to help select the right set of
peers for striping, VoD request data distribution to iden-
tify busy hours and popular content, and the capacity data
(CMD) that gives us the fan out ratio of the number of sub-
scribers that subtends a CO and the measured bandwidth
consumption of these subscribers. This data was analyzed
over a period of one month. We discuss only a few that are
relevanttoZebroidinthefollowingsubsections.
2.3 VoD Data
The anonymous VoD request data provide information on
the purchase timestamp, content title, duration, price and
genre. VoD request data was provided by a national IPTV
service provider covering a footprint of over a million homes
and multiple VHOs. Recent data was used from 2009 over
a period of one month. Joining the purchase data with the
CMD data allows us to associate the VoD requests with the
corresponding DSLAM and CO.
Figure 2 shows the request distribution by hour across all
the CO’s under one particular VHO. If we consider 1500 re-
quests as the high threshold, the chart shows that the peak
hours fall between 8pm and 11pm every night, with Sat-
urday night enjoying the highest number of VoD requests.
On the other hand, if we consider 500 requests as the low
threshold, then 2am to 8am would be the idle hours for the
VoD traffic, an ideal time for striping popular VoD titles -
assuming few other network activities are going on at the
same time. In addition, there is a significant jump in day-
time viewing on Saturday and Sunday from 9am to 5pm,
with the number of requests approaching those of the peak
hours during weekday evenings. This calls for potentially
different content striping and placement strategies between
weekdays and weekends. The VoD request data also gives
us the popularity distribution to help us determine the most
popular video titles to stripe across STBs.
2.4 Power State Data
Power State data (PSD) allows us to determine when a
particular STB was turned on or off (either by the user or
116