Embed Size (px)
Citation preview
Watching Television Over Nationwide IP MulticastPaper ID # 1569058648
Meeyoung Cha∗, Pablo Rodriguez∗, Sue Moon†, and Jon Crowcroft‡∗Telefonica Research, Barcelona †KAIST, Korea ‡University of Cambridge, UK
Abstract—After many years of academic and industry work,we are finally witnessing a thriving of IP multicast in largescale deployment of IPTV services. Based on a trace of 250,000users, we provide an extensive study of one of the world’s largestIPTV networks. As opposed to traditional broadcast TV, IPTVallows for far more accurate traffic analysis on how we watchtelevision. Using detailed channel switching events collected over700 DSLAMs, we identify for the first time previously hiddenuser watching patterns. Our trace also permits us to contrastand compare future IPTV architectures such as a cooperativeP2P and IP multicast system, assessing the potential benefitsusing real data rather than speculation. Last, but not least, wepresent the result of several user clustering algorithms basedon a variety of viewing patterns, laying the path for new andimproved market opportunities like personalized advertising andsocial recommendation engines.
Index Terms—IP Multicast, IPTV, TV viewing behavior, Pop-ularity, P2P, User classification, Recommendation
I. I NTRODUCTION
IP multicast was devised over 20 years ago [6], but for mostof that time has seen little large-scale commercial deployment.Speculation about reasons include critiques of its scalability,potential security threats, and lack of plausible pricing mod-els [5], [7], [8], [12]. Instead, one-to-many communicationhas been implemented and thrived in other forms such asinfrastructure-based overlays (e.g., Akamai) and end-systempeer-to-peer multicast (e.g., PPLive, Zatoo, Joost).
However, long after it was anticipated by academia andindustry, IP multicast is finally transitioning from vision topractice, at least within single domains. Recent years showeda marked uptake of commercial grade live broadcast TVand video-on-demand offerings a.k.a. IPTV, examples beingPCCW’s IPTV in Hong Kong, France Telecom’s MaLigne TVin Lyon, France, Telefonica’s Imagenio in Spain, and AT&T’sU-verse in Texas, United States. In spite of old concerns, IPmulticast has shown itself to be scalable (serving nearly amillion users), secure (providing pay-per view channels andVoD), profitable (as one of the key next-generation sources ofrevenue to service providers), and even cost-effective (com-pared to other designs).
In this paper, we study one of the largest IPTV servicesin the world to understand how we watch TV. Based onover one-month real-world trace across 700 DSLAMs, weanalyze the TV viewing patterns of a quarter million IPTVusers. To the best of our knowledge, this is the first large-scale, in-depth study on IPTV viewing habits. Our trace alsopermits us to contrast and compare future IPTV architectures,assessing the potential benefits using real data rather thanspeculation. Our vision for the future architecture supports
rewinding or fast-forwarding to any position in time, freefrom the broadcaster’s schedule. As a first step, we explorethe potential for a cooperative peer-to-peer (P2P) and IPmulticast system in providing a simple rewind functionality.We also contrast alternate content distribution strategies forIPTV, such as content distribution networks (CDNs) and P2P.Our study ascertains the sweet spots and the overheads ofserver-based unicast, multicast, and serverless P2P for futureIPTV architecture.
Finally, supporting service enhancements is very importantin IPTV businesses, as it leads to customer satisfaction. Under-standing TV viewing behavior in the old days relied on phonecall surveys or attaching specialized monitoring boxes for se-lected users. Often surveys were limited to regional coverage.Now, nationwide deployments and the bi-directional charac-teristics of IP multicast make it easy for service providersto monitor user behaviors closely and continuously. To thisextent, we profile users based on their channel switchingsbehaviors (e.g., how often users browse or view channels, orbecome inactive), based on frequently viewed channels, andbased on their active times. Such clustering can be later used inpersonalized advertising and social recommendation engines,assisting users with the selection of programs (from potentiallyendless list of programs in the future) and provide “out-of-the-box” experience.
In the following, we give a brief overview of the multicastIPTV service architecture.
A. IPTV Multicast Service Architecture
Figure 1 illustrates a typical multicast IPTV servicearchitecture, where TV head ends source IPTV contentsto DSLAMs (Digital Subscriber Line Access Multiplexers)through a single ISP (Internet Service Provider) backbone.Customers subscribe to the quality-assured IPTV, the IP phoneservice, and the best-effort Internet access from the ISP.DSLAMs located at regional networks aggregate traffic fromhundreds or thousands of users and connect to the high-speedIP backbone. For the real-time IPTV service, a TV head endstreams live broadcast of all the channels across DSLAMsthrough bandwidth-provisioned multicast trees. Due to limitedaccess bandwidth at the last mile (i.e., from a DSLAM to the
homegateway STB
PC
TV
DSLAM
customer premiseTV
headend
ISPIP backbone
Internet phone
Fig. 1. Typical multicast IPTV service architecture
2
home gateway at the customer premise), not all TV channelsare delivered to customers all the time. A DSLAM extendsor prunes the multicast trees dynamically in the directiontoward the customers’ set-top boxes (STBs), based on thechannel switching signals. The set-top box translates a channelswitching event from a user to a pair of Internet Group Man-agement Protocol (IGMP) messages: one to alert the user’sdeparture from a multicast group of one channel and the otherto join another multicast group of a new channel. A singleDSLAM can process up to thousands of IGMP messages persecond, which translates to capacity for hundreds of STBs.Our analysis is based on a large collection of IGMP messagescollected from all DSLAMs within a national backbone.
ISPs employ quality-of-service guarantee at last mile byallocating the highest priority to VoIP traffic, quality-assuredbandwidth to IPTV services, and the rest to the best-effortInternet traffic. Figure 2 illustrates an example bandwidthprovisioning over the copper link joining the DSLAM anda household. At the moment most ADSL modems that arealready deployed can support bandwidth for one or more IPTVstreams depending on the video codec rate (e.g., one MPEG2channel or two MPEG4 channels with 5Mb/s provisioning).
Best-effort Internet(1 Mb/s)
VoIP
Quality-assuredIPTV services
(5 Mb/s)Broadband
access(6 Mb/s)
Video
Encapsulation
IRDAudio channels
Fig. 2. Bandwidth provisioning for quality-assured services
The rest of the paper is organized as follows. In§2, weintroduce the trace and analyze diverse aspects of TV viewinghabits.§3 investigates a cooperative P2P and IP multicast sys-tem to provide rewind functionalities, and§4 further contrastsand compares the IP multicast design with alternate contentdistribution strategies for IPTV.§5 analyzes TV viewingpatterns from the users’ perspective. Here we cluster usersbased on their channel switching patterns, preferred set ofchannels, and active times. Finally, we present related worksin §6 and in§7, we conclude.
II. A NALYSIS OF TV V IEWING BEHAVIORS
With a wide range of real time data IPTV provides, it isnow possible to carry out a far more detailed study on TVviewing habits than ever before. In this section, we introduceour trace and carry out diverse set of analysis, for instance,the total views by program, views by time of day, and averageminutes watched per household.
A. Trace Methodology
To understand the scale of multicast deployment and theuser behaviors in channel switching, we obtained a hugecollection of IPTV channel switching event logs from anoperational backbone provider. Our trace of 200 GB spans overa month from April 17 to May 30, 2007, and records channelswitching behaviors of 250,000 or a quarter million users.The collected IGMP event log includes the message type,
timestamp in seconds, and the IP addresses of the DSLAM,the STB, and the multicast group. We pre-process the eventlogs by excluding events of non-video multicast groups1. Wethen chronologically sort IGMP join messages and count thenumbers of viewed channels and channel switchings. Table Isummarizes the daily statistics of our trace. The number of set-top boxes in the table is smaller than a quarter million, sincenot all users turn TV on everyday. The number of channelswitchings clocks 13 million on the average.
TABLE IDAILY STATISTICS ON THE SCALE OF THEIPTV SERVICES
Size # DSLAMs # STBs # Channels # Channel switchings4GB 700 200,000 155 13 million
B. Channel Holding Time
One concern in understanding the TV viewing behavioris that viewers leave the IP set-top box on and receivingdata even when the television is off. Identifying active andsilent periods of users is not trivial. We first look into thedistribution of channel holding times or the time betweenchannel switchings. Figure 3(a) shows a histogram of channelholding times on a representative day. We observe spikesaround 2, 4, 6, and 12 hours, which gives us an idea of thenatural long-term off periods, for instance, sleeping hours orin-between dining hours. Figure 3(b) shows the cumulativedistribution function of the channel holding times. The slopeof the curve changes around 1 minute and again around 1 hour,indicating different users’ behaviour. Based on this observationwe consider channel holding times between 1 minute and 1hour as aviewing session. We further consider channel holdingtimes shorter than 1 minute asbrowsing (or surfing)and thoselonger than 1 hour asaway periods.
0 6 12 18 24 hours2 41e−2
1
1e2
1e4
1e6
Channel holding time (binned 1 sec)
Num
ber
of c
hann
el s
witc
hing
s
1 10sec 1min 1 2 24hrs0
0.2
0.4
0.6
1
0.8
Channel holding time (binned 1 sec)
CD
F
(a) Histogram (b) CDFFig. 3. Channel holding time of a representative day
C. Session Time Distribution
Based on this heuristic to identify viewing sessions, Fig-ure II-C shows various TV viewing statistics on a daily basis.We observe that an average user watches TV 2.54 hours perday and 6.3 channels per day, while each session lasts onaverage 1.2 hour. Note that we refer to each set-top boxas a user, even though it is typically shared by multipleindividuals in a given household. This shows some similaritiesand discordance with traditional survey results. Accordingto Neilsen ratings in 2005, the average household watchedtelevision for approximately 8 hours per day. While othersurveys report that an average adult watches TV for 3 hoursper day.
1Some multicast groups are used to control the remote system (e.g.,bootstrapping and updating set-top boxes).
3
00:00 06:00 12:00 18:00 24:000
2
4
6
8
10x 10
4
Time−of−day (binned 30 min)
Num
ber
of v
iew
ers
(a)
00:00 6:00 12:00 18:00 24:000
2
4
6
8
10x 10
4
Time−of−day (binned 30 min)
Num
ber
of v
iew
ers
weekend
weekday
(b)
Mon Tue Wed Thu Fri Sat Sun0
0.5
1
1.5
2
2.5
3
Day−of−week
Vie
win
g ho
urs
per
hous
ehol
d
18% increase on weekends
(c)Fig. 4. Number of viewers over time. Time-of-day trend in (a) and (b) shows peak hours around 8AM, 3PM, and 10PM, which closely coincide with thedining hours of the monitored population. The number of viewers is much larger on weekends, late morning, which is identified as high viewing on children’sprograms and cartoons. Day-of-week trend is shown in (c), where the total time served across all users is much longer over the weekends.
0 6 12 18 240
0.2
0.4
0.6
0.8
1
Daily viewing hours per uesr
CD
F
Avg = 2.54 hours
2 4 6 80
0.2
0.4
0.6
0.8
1
Daily number of sessions per user
CD
F
Avg=2.1
0 1 2.5 24 hrs120
0.5
0.91
Average session length of users
CD
F
Avg = 1.2 hour
0 10 20 30 40 500
0.2
0.4
0.6
0.8
1
Number of channels viewed per day
CD
F
Avg=6.3
Fig. 5. Various statistics based on sessions
D. Channel Popularity
Now we look into the relative popularity of channels.Figure 6(a) shows the aggregate fraction of viewer shareaccounting tor-th popular channels. Top 10% of channelsaccount for nearly 80% of the viewer share, indicating thatchannel popularity follows the Pareto Principal (or 80-20 rule).This is consistent across different times of day. Figure 6(b)shows the plot of channel rankings against the number ofviewers. We observe that the distribution is Zipf-like for toppopular channels, while the popularity decays fast for non-popular channels (ranked 30th or below). Zipf-like popularityof top channels has also been shown in P2P-based IPTVservices [11].
0 20 40 60 80 1000
20
40
60
80
100
Normalized channel rank
Agg
rega
te v
iew
er s
hare
(%
)
8AM3PM10PM
(a) Pareto principal
100
101
102
100
102
104
Channel rank
Num
ber
of v
iew
ers
10PM3PM8AM
(b) Zipf-like popularity
Fig. 6. Multicast channel popularity
E. Number of Viewers Over Time
Figures 4 shows the time-of-day and day-of-week trends onthe number of viewers. We consistently observe strong peaks
for particular times of day (e.g., 3PM, 10PM). However, thisdoes not reflect the profile of individual users. In§5, we useclustering to identify the different patterns of usage times.Increase in TV viewing during the weekends has been alsoshown in the survey of workers, where the viewing hours overthe weekends increased by 30-40% [1].
F. Zooming Into Per-Program Viewing Behavior
Now we focus on how viewers leave and join a particularprogram. Let us first zoom into a single popular program.Figure 7 shows the user behavior over a popular soccer gameheld in May 23, the final match of the European ChampionsLeague. We plot the number of viewers, the viewer share,and the number of inbound and outbound channel switchingsto the event channel. Due to the specifics of a sport event,there are four parts in the program. We see that a significantfraction of viewers all together leave the channel duringhalf-time and re-join after the half-time, reflecting a verystrong correlation amongst viewers in their behaviors. We alsonote that many viewers join or re-join the program after thebeginning of each part. Motivated by this, we later explorethe possibility of feeding latecomers with missed scenes in apeer-to-peer fashion. For other types of programs (e.g., soapopera, news, comic), we have also found strong membershipamongst the viewers per program, with most viewers beinghighly correlated about when they join and leave channels.
An interesting point to note from Figure 7(c) is the constantset of users that depart the channel at any point in time. Onecould relate this behaviour to channel surfing, where usersbrowse in and out the channel very fast. However, in ouranalysis, we have ignored those users that do not watch thechannel for a sustainable period of time (e.g. more than fewminutes). It is surprising to note that even after discountingsuch users, the churn is still very high, with about 10% ofusers constantly departing the channel.
G. Multicast Group Density
As described before, the IP multicast distribution in thebackbone uses static trees, where all channels are delivered toall DSLAMs at all times, even when no user is watching them.Only the tree branch from DSLAM to customers dynamicallychanges. Here we explore the potential benefits of an IPTVsystem using multicast trees that prune back if there are no
4
20:00 21:00 22:00 23:00 24:000
5
10
15
x 104
Time of day (binned 5 min)
Num
ber
of v
iew
ers
program duration
event channel
all channels
(a)
20:00 21:00 22:00 23:00 24:000
10
20
30
40
Time of day (binned 5 min)
Vie
wer
sha
re (
%)
program duration
(b)
20:00 21:00 22:00 23:00 24:000
0.5
1
1.5
2
x 104
Time of day (binned 5 min)
Num
ber
of c
hann
el s
witc
hing
s
program duration
Inbound
Outbound
(c)Fig. 7. Detailed user behavior on a May 23rd soccer match. The program includes four parts: first-half, half time, after-half, and awarding ceremony. Thenumber of viewers, viewer share, and channel switching clearly reflects these partitions. At its peak, the program clocks over 35% of the viewer share.
receivers. To this extent, we measure the tree density, which isthe total number of multicast groups across all DSLAMS withat least one active user. Because users may leave the set-topbox on when they turn off the TV, we exclude those userswho did not show any channel switching action for longerthan 1 hour. We have also tested with larger inactivity periods,obtaining similar results. Figure 8 shows the tree densityover a representative day. We observe an order magnitudeof difference between the tree density of static and dynamicmulticast trees. In fact, density of the dynamic multicast treeis surprisingly low (e.g., 17% on average), suggesting thatthe IPTV traffic carried over the IPTV backbone is oftennot consumed by any user and that an alternative designcould significantly reduce the traffic in the backbone (e.g.,dynamically pruning the multicast trees).
00:00 06:00 12:00 18:00 24:0010
3
104
105
Time of day (binned 1 min)
Tot
al n
umbe
r of
mul
ticas
t gro
ups
Avg=17%
From TV head ends to all DSLAMs
From DSLAMs to users
Fig. 8. Multicast group density
This low tree density is largely determined by the DSLAMto STBs aggregation ratio. For the current IP multicast designto achieve maximum efficiency, at least one user per DSLAMshould watch each channel. However, most DSLAMs coverfew hundreds of users and these users are not active allthe time. Moreover, users’ interest is often focused on fewchannels. We have indeed found that the average number ofchannels viewed per DSLAM is only 17% of all channels.We expect that in the future, DSLAM to STB aggregationratio will be even lower since more and more DSLAMs aredeployed closer to the end user to reduce the attenuation overthe last mile. Hence we expect the multicast tree efficacy tobecome even lower.
III. A C OOPERATIVEP2PAND IP MULTICAST SYSTEM
Advanced VCR features allow users to jump back in timeand playback passed scenes – known as Replay TV. Current
IPTV offerings provide this service in a standard client-serverfashion, as part of the VoD service. Because individual usersrequest for different positions in the past, video servers useunicast rather than multicast delivery. A big drawback in thisserver-client approach is scalability, as the server workloadand bandwidth grows linearly with the number of users.
Here we consider the potential for a collaborative P2P andIP multicast architecture, where rewind function is providedthrough a P2P network of STBs (and by VoD servers ifnecessary). For the purpose of this paper, we limit ourselvesto a VCR operation where users joining a TV program wantto jump back to the beginning of it, e.g., a user wantingto watch an ongoing movie from the beginning (our resultscan be easily generalized to the case of serving any pointbackward or forward in time). It is important to note that suchrewind function is different from that provided by personalvideo recorders (PVR) (e.g., TiVo). PVR also provides rewindfunctions, however only to those scenes locally stored. Ourrewind functions supports streaming the passed scenes for anynewly joined channel. We assume that all streamed content isstored locally at users’ set-top boxes2. This stored content isused for serving other users as assistance to the Replay TVvideo server.
P2P distribution has previously shown to dramatically re-duce the video server load by distributing the load to peers [9].However, the efficacy of a P2P system to support the rewindfunctions is unclear for a number of reasons. First, as view-ers freely switch channels, there may be not enough peerswho stored the content from the beginning of the program,decreasing the serving capacity. The situation aggravates forunpopular programs and for low usage periods. Second, peersbecome unavailable when they serve other users. Schedulinga globally optimal streaming across multiple channels is avery complex problem, and remains yet to be solved. Third,a topology-oblivious P2P may incur a network cost that ishigher than strategically-positioned redundant video servers,or even IP multicast, as each P2P communication may turninto a unicast stream crossing the nationwide network.
To assess the potential for a cooperative P2P system, weperform a trace-driven simulation. We make several assump-tions. Video content is divided into blocks of 1 minute. A
2With 2-4 Mb/s of streaming rate, 21-43GB of storage space is required tostore one-day-long data. We assume STBs are equipped with enough storage.
5
00:00 06:00 12:00 18:00 24:000
1
2
3
4
5
x 104
Time of day
Req
uest
vol
ume
Vod server load 5%
Served by local peers 80%
Total traffic served 100%
(a) Fraction of locally-carried traffic
0 100 200 300 400 5000
20
40
60
80
100
Size of DSLAM (Number of set−top boxes)
Loca
lly s
erve
d tr
affic
(%
)
Average
(b) Locality versus DSLAM size
0 10 20 300
60
20
40
80
100
Channel ranks based on requests
Tra
ffic
serv
ed (
%)
locally served in P2P
(c) Locality versus channel rankFig. 9. Performance of the locality-aware P2P
P2P request is made for each block. Users have enoughdownstream bandwidth to receive both live IPTV multicaststream and VCR rewind P2P stream simultaneously. We alsoassume that the upload capacity of each peer is equal to itsdownload capacity. Note that this is a reasonable assumptionin a controlled environment as in IPTV; the ISP controls thebandwidth allocation. P2P is used only for patching the missedscenes, while the ongoing scenes are received via IP multicastand stored locally for later viewing. For other possible designsof patching in multicast video streaming, we refer to a goodbody of work in [2], [10], [13]. A tracker provides an up-to-date list of viewers for each channel. We later consider alocality-aware P2P system where a centralized tracker keepsinformation about which users are watching which channelat each DSLAM and matches local DSLAM peers wheneverpossible.
If a peer possesses requested past blocks of a program andhas enough upload capacity, one is deemed available to serveother peers. If a peer fails to find any available peer within agiven number of trials, then the VoD server immediately servesthe peer. We assume that a peer will query up to1, 000 peersin our simulation before giving up finding potential servingpeers. A peer abandons the VoD server as soon as new peersbecome available. P2P patching traffic also stops when therequesting peer changes the channel.
To perform our simulation we use the TV program schedulefor each particular channel and map the program schedule withthe channel switching logs at each time. In our trace, some ofthe channels had varying schedules in different regions. Ourtrace did not include this meta-information about the scheduleand the mapping of network devices to regions. Hence, wehave manually identified 30 channels with common programschedules and focused on only those channels for assessingP2P system. We should also mention that these 30 channelsaccount for over 90% of traffic.
Figure 9(a) shows the total amount of traffic required tosupport VCR operations over time, the amount of traffic thatcould be served by peers in the local DSLAM, and the VoDload that could not be served by the P2P system. The totaltraffic shows a time-of-day trend. Note that under a pure IPTVarchitecture, all the VCR load would be directed to the VoDservers (top-line). With an assistance of a P2P system, weare able to dramatically reduce the VoD server load to mere
5%. In a P2P system, the serving capacity for any particularblock increases over time, as peers requesting a block alsobecomes a serving peer for that block after the download.Hence latecomers in the program can easily find availablepeers.
With a locality-aware peer selection, a remarkable 80% ofthe traffic can be served from within a DSLAM. High localityreflects a high correlation between the local users and thechannels they watch. This is important, since a large fractionof requests can be handled within the DSLAM domain andthe backbone cost can be avoided for this traffic. Naturallythe DSLAM size affects the level of locality. In Figure 9(b),we show the locality efficacy against the size of a DSLAM.The vertical axis represents, for a given DSLAM, the fractionof locally served traffic against the total traffic served forthe users within the DSLAM. We observe that the localityincreases exponentially with the size of the DSLAM. Notethat even for very small DSLAMs, the benefits are noteworthy.Figure 9(c) compares the locality against the channel popular-ity. We observe that popular channels have higher chances ofbeing served locally, and even less popular channels enjoyhigh levels of locality.
0 20 40 60 80 100 1200
5
10
15
20
25
30
35
40
Rewind block size (1 block=1 min)
Num
ber
of p
eers
ass
ited
patc
hing
MaxAvgMin
Fig. 10. Communication overhead versus request size
One other metric of interest when designing a P2P systemis how many peers are required to assist in patching. Figure 10shows this value as a function of the rewind period. The graphshows the maximum, the average, and the minimum number ofpeers assisted patch streaming. We observe a steady increasein the number of peers as the covered rewind period increases.However, the number of peers required is always below 30.If one calculates the slope of the plot, it shows that one hasto switch peers once every11 minutes on the average. Thisvalue is very similar to the average period during which a peerwatches each channel, which is12 minute. We also note that
6
the graph becomes noisy after 60 blocks. This is because thereare fewer of such incidents.
IV. EXPLORING ALTERNATE L IVE-TV A RCHITECTURES
In §3, we have investigated how a P2P system couldaugment an IP multicast service by enabling scalable VCRcapabilities. In this section, we consider the possibility ofdelivering the live TV signal through combinations of networkarchitecture choices, such as a Content Distribution Network(CDN) (e.g., Akamai) or a P2P solution (e.g., Zatoo, PPLive,Joost). In a CDN, the TV head end sends out streams to re-gional servers close to the DSLAMs. Such intermediate serversreplicate and forward the live broadcasts to the individual usersvia unicast. Another popular architecture is P2P. In P2P-basedIPTV system, the TV head end would send out streams to asmall subset of set-top boxes, which in turn would serve otherpeer set-top boxes. Topology-oblivious P2P system has beenshown to inadvertently shift load from video servers to ISPs,while locality-aware P2P system could alleviate the load offISPs [14].
Unlike IP multicast, alternative designs do not take intoaccount the underlying service infrastructure, resulting inhigher overall network usage. To illustrate the contrastingdifferences between the architectures, we use the toy examplein Figure 11. We focus only on the total amount of trafficthat travels over the boundary of the ISP backbone (i.e. thetraffic carried between DSLAM and the first IP router). Wefocus on this part of the network, not on the backbone cost.congestion. As multimedia contents dominate traffic volume,the link between the IP router and the DSLAM is immediatelyaffected by any increase in traffic and is always a top candidatefor congestion. We do not consider the backbone cost, for itdepends on the network topology and ISP-dependent designchoices, and is orthogonal to our problem. Figure 11 shows asimplified ISP network with a video source (national TV headend or regional servers, in case of a CDN), an edge IP router, aDSLAM, and a STB. In case of IP multicast, based on our toyexample, the access network cost is2. In a CDN architecture,the regional server sends out redundant unicast streams toindividual users as shown in Figure 11(a), resulting in the costof 4. In a locality-aware P2P, the leftmost peer receives theTV stream from the source, then serves another local peer. Athird peer receives streaming from a remote peer, then servesits local peer. We assume that local traffic can be re-routed topeers of a common DSLAM and is not forwarded up to theIP router. As a result, the network cost is reduced to3 as inFigure 11(b). Figure 11(c) shows the worst-case scenario ofa topology-oblivious P2P, where one peer receives TV streamfrom the source, while the rest of the peers receiving fromremote peers. As a result the network cost is7, which is morethan three times higher than IP multicast.
We consider the following five cases of network architec-tures: 1) static multicast tree; 2) dynamic multicast tree; 3)CDN; 4) topology-oblivious P2P; and 5) locality-aware P2P.As our IPTV channel switching logs capture the user behaviorof a large-scale deployed service, they offer us a very unique
cost = 4 cost = 3 cost = 7
Source
IP router
DSLAM
STB
(a) CDN (b) Locality-aware P2P (c) Topology-oblivious P2P
Fig. 11. Illustrative example of alternative architectures
opportunity to compare all these five design choices underrealistic user demand portfolio. We assume that CDN serversare co-located with the IP routers in our operational multicastIPTV network. In both P2P scenarios, we assume that a singleuser per channel receives the channel from the source and therest of the users stream one another. In topology-obliviousP2P, peer selection is random. In a locality-aware P2P, peersfirst search for seed nodes within their DSLAMs, then searchoutside. Other details of the P2P are similar to§4.
Figure 12(a) compares the network access cost of the fivedesigns. From this figure we make several observations. First,the static IP multicast tree consistently requires high cost, dueto the low DSLAM to STB aggregation ratio as discussedin §II-G. On the other hand, the dynamic multicast tree appearsas the all-time most economical design, as expected. Second,the cost of CDN architecture closely follows the time-of-day effect, as the CDN design utilizes unicast streams toindividual viewers. This implies a significant CDN serverload during peak usage hours. Finally, comparison of P2Parchitectures show that a sophisticated locality-aware peerselection will dramatically reduce the network access cost (asthat comparable to the dynamic IP multicast tree). However, atypical random peer selection (which is already used in manyP2P systems) results in much higher cost than any designsduring the peak usage hours, and generates up to6.2 timesmore traffic than a dynamic multicast solution.
To understand the drastic difference between the two P2Parchitectures, we further look into how much traffic was servedby local users in Figure 12(b), indicating strong locality. Theaverage fraction of traffic served by local users shows a starkdifference of 87% and 0.2%, respectively. In is interestingto observe that the request volume served locally follow thetime-of-day pattern for locality-aware P2P, which explainshow the cost remained relatively steady during peak hoursin Figure 12(a).
Overall, we have observed that a poorly designed P2P IPTVsolution can have a significant impact in the ISP network. Atthe same time, whilst a dynamic Multicast solution alwaysprovides the best performance possible, a P2P solution withlocality has an overhead that is only slightly higher to that ofa well-thought out IP multicast TV service paving the way fornew TV delivery architectures.
V. V IEWING PATTERN FROM USERS’ PERSPECTIVE
Having gathered data from a massive number of users,channels and programs, we have the opportunity to take a
7
00:00 06:00 12:00 18:00 24:000
5
10
15
x 104
Time of day (binned 1 min)
Net
wor
k ac
cess
cos
t
Topology−oblivious P2P
Static IP multicast tree
Dynamic IP multicast tree
CDN (unicast)
Locality−aware P2P
(a) Network cost comparison across all designs
00:00 06:00 12:00 18:00 24:000
2
4
6
8x 10
4
Time of day
Req
uest
vol
ume
Total traffic served for each P2P 100%
Traffic served by local peers in locality−aware P2P (87%)
Traffic served by local peers in topology−oblivious P2P (0.2%)
(b) Performance comparison of the two P2P designsFig. 12. Comparison of network cost of five different architectures
closer look at the behavior of IPTV users. With the help ofvarious clustering and data mining techniques, in this sectionwe extract various user patterns. We can then answer a varietyof questions, such as how viewers surf over TV channels, atwhat point they are likely to start or stop watching a particularchannel, why they may select one channel versus another, andat what time of the day they are most likely to be active.To this extend, we will perform three types of analysis. Inthe first analysis, we infer correlation between different TVchannels based on users’ viewings. In the second analysis,we study how likely users are to be in different states (e.g.viewing, browsing, or being away) and how they transitionacross states. In the third analysis, we classify users based ontheir temporal TV viewing patterns.
Across this section, we treat channel switching events as asequence of user states. In particular, we identify three modesof viewing from a user’s perspective: viewing a program,browsing through channels, or being away from TV (noviewing at all). In order to determine users’s viewing modes,we refer to Figure 3 and use the thresholds explained in§2to delineate one mode from another. Let us first compare thekey characteristics of the three states. Figure 13(a) shows theCDF of the number of occurrences for each state across allthe IPTV users. The plot is based on a single representativeday’s trace. The graph shows that viewers browse a medianof 27 times, view 9 times, and go away 3 times a day. Wealso observe extreme cases for viewing over 700 times andbrowsing over 1900 times a day. Figure 13(b) shows, for theidentical day trace, the average time spent on each state acrossthe users. We observe that users skim through channels for amedian of 10 seconds while browsing, view for 10 minutes,and be away for 5.5 hours, respectively. Note that the plotshows clear boundaries between the three modes, illustratingour expedient choices for threshold values.
In the following, we present three analyses based on thethree-state user model.
A. Correlation Across Channels
We commence by identifying channels that are viewed bythe same group of users. We study the possible correlationacross channels by identifying channels that are viewed by thesame group of users. If two channels have the same viewers,then we pair the two channels. Such pairing identifies a group
100
101
102
103
104
0
0.2
0.4
0.6
0.8
1
Num. occurances for each state per user
CD
F
AwayViewBrowse
10sec 1min 10min 1 24hr60
0.2
0.4
0.6
0.8
1
Avg holding time for each state per user
CD
F
Browse View Away
(a) Frequency within a day (b) Time spent on each stateFig. 13. Comparison of the three user states
of target users that watch similar programs. This is potentiallyvery useful since content providers and advertisement compa-nies could tailor their marketing strategies to each group ofusers.
To identify the channel pairs that are viewed together, weuse a one week trace. To filter out light users that are notstatistically representative, we only consider logs from thoseusers who watched more than two channels and went througha View state at least ten times during the monitored period.Then we construct a binary vectorxi for each channeli, suchthatxi(u) = 1 iff useru watches channeli. We only considerevents of View states and exclude those events of Browse orAway states. Our clustering technique consists of the followingthree steps: 1) We compute the cosine coefficient,ρi,j , betweenany pair of channelsi and j as:
ρi,j =xT
i · xj√xT
i · xi ·√
xTj · xj
. (1)
The cosine coefficient is widely used to quantify the similaritybetween two vectors. Channels that are always viewed togetherhave a correlationρi,j = 1; 2) We transform the cosinecoefficient to have either 0 or 1, based on a threshold value. Wesetρi,j = 1 if the value ofρi,j is greater than the threshold,and ρi,j = 0, otherwise. If we set the threshold high, thenno pairing of channels is likely. If low, then all channels willbe paired with each other and one huge cluster will emerge.Note that the cosine coefficient is not transitive in that if evenchannels A and B are paired and channels B and C are paired,channels A and C are not always paired. If the threshold ishigh, then it becomes more likely that channels A and C bepaired. Our results will reveal how far this type of transitivityholds in real life. We use a threshold value of0.8 in our data;3) Finally, we pair channels with cosine coefficients above
8
the threshold, and find the connected clusters from a graph ofpaired channels.
Figure 14 shows our channel clustering result. Our traceshows 5 major connected components of 15 channels, acrossover 150 channels. A node represents a channel and a linkbetween two nodes represents a cosine coefficient above thethreshold value. Note that any two nodes within the samecluster are connected, but may not share a link. When wecheck the genre of each channel, surprisingly, we observe aclean matching of each cluster to a single content type or topic.The largest cluster belongs to a group of six free-to-air nationalchannels. Other clusters are focused on music, movies, anddocumentaries. This indicates that a user’s channel selectionis highly driven by the content topic.
6 5
3
1
111
112
233
234
42
43
4
NationalsMusic2 Movies Documentals
2
110
116
118
Music1
Fig. 14. Channels within the same cluster show high semantic similarity
Once we have paired channels into clusters, we can nowidentify larger groups of users by a given cluster or a combi-nation of clusters. For instance, 40% of users only watch to theNationals clusters, while 30% of users watch a combinationof channels in Nationals and Music1. Channel pairing andclustering provide a natural way to identify and expand usersof similar interests.
B. Transition between User States
Now we focus on the three modes of a user behavior(e.g., viewing, browsing, and away) and examine how frequentusers are on each state and how they jump from one state toanother. In order to see such transitions, we build a Markovmodel based on the three states. From our trace, we identifyfor all users all events where a transition from one modeto another takes place and count the number of transitionsbetween modes. Note that the time spent on each state is notreflected in this model; in a time-based model, user patternswould not emerge so clear as some states dominate others.
Figure 15 depicts our 3-state model along with the statetransition probabilities. This model reflects the average TVviewing behavior across all users. The sum of the outgoingprobabilities from each state is1.0. Note that a user could gofrom an Away state to another Away state with the probabilityof 0.21. This is the case when users briefly watch a newchannel but go away because of lack of interest. We use aone-week trace in building our model. As expected, from allthree states, the transition to Browse is the most likely. AfterBrowse, users go Away more than stay on to view anotherprogram. When a user returns from the Away state, one ismore likely to begin with Browse than settling down on View.
Our Markov model in Figure 15 represents the averagechannel switching behavior of all users. The behavior ofindividual users may vary greatly from this global pattern.Now we focus on individual users and see if we can find a
Browse Away
View
0.770.19
0.040.57
0.35
0.08
0.47
0.32
0.21
Fig. 15. 3-state Markov model with state transition probabilities
cluster of users with a similar behavior. To this extend, wefirst build the three-state Markov model for each individualuser, and then compare the stationary probabilities with thoseof the global model in Figure 15.
Then we cluster users based on how far away they arefrom the ”average” behaviour as follows: a) If the stationaryprobability of Browse of an individual user is greater than thatof the global Browse state probability of0.703 by θ1, thenwe assign the user to “Heavy Browsers” group; b) Likewise,if the probability of View state is greater than0.237 + θ2,then we assign the user to “Focused Viewers” group; b) Ifthe stationary probability of Away is greater than0.060 + θ3,then we assign the user to “Light Users” group; 4) Otherwise,we assign the user to “Average Viewers” group. We use acommon threshold ofθ. = 0.1, which divides users in ourtrace into proportionally sized groups while maintaining per-group characteristics. Table II summarizes the characteristicsof each cluster with its cluster size.
TABLE IICHARACTERISTICS OF USER CLUSTERS BASED ON USER STATES
Clusters Average Heavy Focused LightViewers Browsers Viewers Viewers
Size 37% 15% 25% 21%Tot. viewing time (hr/day) 2.89 1.97 3.25 0.5
Avg. viewing time (min) 12.5 11.1 14.0 11.6# viewed channel 7 6 6 1
# browsed channel 21 32 11 5
We can observe that focused viewers show the largest dailyviewing hours as well as the longest average viewing time.Surprisingly, even though their viewing time is clearly thelongest, they watch more or less the same number of channelsas the average users and heavy browsers. Rather, they viewthese channels multiple times a day, indicating a strong loyaltytoward particular channels. When we compare the numberof browsed channels versus viewed channels, heavy browsersshow significant high diversity in browsed channels, however,interestingly, the number of actual viewed channels is similarto the average users suggesting a strong inertia towards thesame set of channels. The total time spent watching TV perday drops markedly for light users.
C. Temporal Correlation in Viewing
Our final goal is to group those users who watch TV atsimilar hours and study the temporal correlation patterns. Herewe describe the use of nonnegative matrix factorization (NMF)to find a small number of temporal patterns from a quartermillion users. NMF is a powerful method to identify distinctpatterns; for instance, it is used to extract features of nose andeyes from a face image [16] or effectively extract a handful
9
of metagenes from a thousands of genes [3]. We apply thetechnique to find groups of users with temporal correlation.
NMF is an algorithm to factorize a large matrixA into twomatrices with positive entries,A ∼ WH. Matrix A is of sizeT ×N , whereN is the user andT is the time sequence. Weuse an hourly measurement over a week (T = 24 ·7) across allusers and constructAi,j = 1 iff user j watched TV for longerthan 30 minutes atith hour; andAi,j = 0, otherwise. Given apredefined number of clusters,k, the factorized matrixW hassizeT × k, representingk number of signature time patterns.Matrix H of sizek×N represents how well each user fits tothe k temporal patterns.
Figure 16 shows the signature matrixW for three patterns,i.e., k = 3. The number of groups is set to 3 fork based onthe heuristic proposed in [3]. We refer to their work for furtherdetail. The three temporal patterns in user behavior indicatedifferent lifestyles of IPTV users: early birds (midday-driven),night owls (night-driven), and always-on users. Such userprofile is valuable in providing personalized recommendationsand advertisements.
Mon Tue Wed Thu Fri Sat Sun0
1
2
3
4
Met
ause
r ex
pres
sion
pro
file
50%
25%
25%
Fig. 16. Temporal correlation analysis: The relative amplitudes of the threemetausers determine three classes of samples. As there is no sharp boundariesin user patterns, each user may be represented as a linear combination ofthe three metausers. For each user, we select the metauser type of highestmatching. The each pattern accounts for 25%, 50%, and 25% of the users.
VI. RELATED WORK
Many forms of video streaming services are now madeavailable commercially. VoD is one such service, and userbehaviors in centralized as well as in P2P VoD serviceshave been analyzed in detail [2], [4], [10], [18]. These workprovided us with insight to improve service quality consid-ering the popularity distribution of videos, users’ viewingcharacteristics from system’s perspective (e.g., total viewsover time), and more efficient distribution architectures. Anewly emerged service is IPTV. Compared to VoD, supportingquality-assured delivery of high bandwidth live broadcaststreams is a challenging problem. Most current IPTV offeringsare been deployed rapidly over the recent years and exhibitthemselves in different forms such as server-based unicast,multicast, and serverless P2P [5], [6], [15], [17]. In this paper,we study one of the world’s largest IP multicast TV offerings.A nice complement to our work is a study of a P2P based IPTVservice, PPLive [11]. Compared to their study, we not onlystudy the characteristics of viewing patterns and the servicearchitecture, we also further cluster users based on the key
viewing patterns and compare and contrast our architecturewith alternative distribution designs.
VII. C ONCLUDING REMARKS
In this paper we present the first detailed analysis of tracesof a commercial-scale IP multicast TV service. A native IPmulticast TV service allows service providers to monitor andcontrol performance at multiple levels. By matching trafficto the network, timely delivery can be made allowing chan-nel switching time to approximate traditional broadcast TVsystems. At the same time, fine-grain monitoring of channelswitching via logging of IGMP traffic allows detailed, complexanalysis of channel popularity and user preferences. Finally,since the content and service are IP based, other IP servicesmay be integrated that take advantage of this new understand-ing of the behaviour of users, channel and content, which hasto date only been available in a coarse-grain, approximate, andoffline form.
REFERENCES
[1] Time spent on selected free time activities of full time workers. OfficeFor National Statistics, United Kingdom, January 2001.
[2] M. K. Bradshaw, B. Wang, S. Sen, L. Gao, J. F. Kurose, P. J.Shenoy, and D. F. Towsley. Periodic Broadcast and Patching Services:Implementation, Measurement, and Analysis in an Internet StreamingVideo Testbed. InSIGMETRICS/Performance, pages 312–313, 2001.
[3] J.-P. Brunet, P. Tamayo, T. R. Golub, and J. P. Mesirov. Metagenes andMolecular Pattern Discovery Using Matrix Factorization. InProc. Natl.Acad. Sci. USA 101(12): 4164-4169, 2004.
[4] L. Cherkasova and M. Gupta. Analysis of Enterprise Media ServerWorkloads: Access Patterns, Locality, Content Evolution, and Rates ofChange.IEEE/ACM ToN, 12(5):781, 2004.
[5] Y. H. Chu, S. Rao, and H. Zhang. A Case for End System Multicast.In ACM SIGMETRICS, June 2000.
[6] S. E. Deering and D. R. Cheriton. Multicast Routing in DatagramInternetworks and Extended LANs.ACM TOCS, 8(2):85, 1990.
[7] C. Diot, B. N. Levine, B. Lyles, H. Kassem, and D. Balensiefen.Deployment Issues for the IP Multicast Service and Architecture.IEEENetwork, 14(1):78–88, 2000.
[8] P. Francis. Yoid: Extending the Internet Multicast Achitecture. http://www.icir.org/yoid/.
[9] C. Gkantsidis, T. Karagiannis, P. Rodriguez, and M. Vojnovic. PlanetScale Software Updates. InProc. of ACM SIGCOMM, 2006.
[10] Y. Guo, K. Suh, J. Kurose, and D. Towsley. P2Cast: Peer-to-peerPatching Scheme for VoD Service. InProc. of WWW, 2003.
[11] X. Hei, C. Liang, J. Liang, Y. Liu, and K. Ross. A Measurement Study ofa Large-Scale P2P IPTV System.IEEE Trans. on Multimedia, October2007, to appear.
[12] H. Holbrook and D. Cheriton. IP Multicast Channels: Express Supportfor Single-Source Multicast Applications. InACM SIGCOMM, Septem-ber 1999.
[13] K. A. Hua, Y. Cai, and S. sheu. Patching: a Multicast Technique forTrue Video-on-Demand Services. InProc. of Multimedia, 1998.
[14] T. Karagiannis, P. Rodriguez, and K. Papagiannaki. Should InternetService Providers Fear Peer-Assisted Content Distribution? InProc. ofInternet Measurement Conference, 2005.
[15] L. Kontothanassis, R. Sitaraman, J. Wein, D. Hong, R. Kleinberg,B. Mancuso, D. Shaw, and D. Stodolsky. A Transport Layer for LiveStreaming in a Content Delivery Network.In Proc. IEEE, 92(9):1408,2004.
[16] D. D. Lee and H. S. Seung. Learning the Parts of Objects withNonnegative Matrix Factorization.Nature, 401(788), 1999.
[17] PPLive. http://www.pplive.com/.[18] H. Yu, D. Zheng, B. Y. Zhao, and W. Zheng. Understanding User
Behavior in Large-Scale Video-on-demand Systems. InProc. ACMEurosys, 2006.
