Alex Bikfalvi Jaime García-Reinoso Iván Vidal Francisco Valera Arturo Azcorra

Peer-to-Peer vs. IP MulticastComparing Approaches to IPTV Streaming

Based on TV Channel PopularityAlex Bikfalvi Jaime García-Reinoso Iván

Vidal Francisco Valera Arturo Azcorra

Networking Seminar 2

Commercial-grade IPTV• How some telcos stream IPTV?

February 3, 2009

IPTV broadcast

server

Customer premise

Customer premise

Customer premise

Backbone network

ADSL router

Set-top box

TV set

xDSL

xDSL

xDSL

xDSL

DSLAM

DSLAM

DSLAM

IP multicast (static)

IGMP: 1-2 channels


Motivation• Most deployment are walled-gardens

• Multicast has been the preferred technical solution• Current/possible future tends…

• Next generation networks, open to third-party providers• Studies show that over 90 % of channels are watched by

20% of subscribers• Semi-interactive techniques: NVoD• User generated content

• Possible issues for the telcos• Is it still affordable to use multicast?• Even for very unpopular channels?

February 3, 2009


What are we doing

• Why P2P?• Telcos can leverage their set-top boxes to form a P2P

overlay• Main question

• How the TV channel popularity affects the difference in performance

• Dimensions of our analysis• Bandwidth utilization• Multicast scalability

February 3, 2009

Let’s compare IP multicast with an alternative: Peer-to-Peer


Setting up the foundation

The streamingTV watchingThe network

February 3, 2009


Streaming scenario• Hybrid: IP multicast and P2P-based

unicast• 100 TV channels

• P2P-based unicast• Set-top boxes (STBs) are peers• Channel stream is pulled/pushed from/by other

STB(s)• The head-end server is a last resortFebruary 3, 2009

IP multicast connections (P2P) unicast connections

g N–g

N TV channels


P2P overlay• A P2P algorithm handles peer

discovery• I.e. another STB receiving the same channel

• Another dimension to the problem: locality

• Algorithm effectiveness: P2P ratioFebruary 3, 2009

P2P Overlay How it works

Application-layer multicast with random peers

The stream is pushed by another STB receiving the same channel, randomly selected

Application-layer multicast with preferred peers

Same as above, but peers need to meet a set of requirements: bandwidth, connectivity duration

𝜌=v p 2p

v p2 p+v srv=v p 2pv

Number of peers connected to peers

Number of peers connected to the server

Number of peers


Watching TV• Modeling the user behavior• How long a user watches a TV channel:

channel holding time (CHT)• TV channel popularity• TV channel zapping probability• TV channel number of viewers

• The model• Input: CHT and popularity• Output: zapping probability• 10000 users and limited number of popularity

levelsFebruary 3, 2009


Popularity model• What is the channel popularity?

• How often users arrive/leave• How long they watch the channel• It sums the CHTs of all viewers during the

observation period• The popularity of all channels:

February 3, 2009

Time

Number of viewers

Popularity:

Observation period


Zapping probability• The probability of changing to a TV

channel

• Relationship with popularity

February 3, 2009

i

j

k

l

m

np ji

pkipli

pmi

p¿

pi=∑j=1j ≠i

N

p ji

pi≈𝒫i𝒫∗

Popularity of channel i

Popularity of all channelsZapping probability of channel i

Sufficiently large observation period and all channels have

the same probability distribution of the channel

holding time


Viewers• The average number of users watching a

channel

February 3, 2009

v i=𝒫i

T≈U ⋅ pi

Observation periodNumber of users (10000)

Time

Number of viewers Observation period

Popularity: pi

v i


Our model• Define channel popularity levels• Abstract, not based on a measurement• The effects to be easy identifiable• If possible, popularity to translate in easy

zapping decisions• CHT: measurement study (Cha et al.)

February 3, 2009

Number

M 1+M 2=N Q1+Q2=1

pi∼𝒫i


Network topology• Access network like DSL• One link (hop) from backbone to customer

premise• Backbone network using BRITE• 100 routers / 50 edge routers• Ratio edges-to-nodes (m): 1, 2, 3, 4• Average path length between two nodes: lu• Average multicast tree size from a source to a

group of g nodes: lm= f(g)

February 3, 2009


More on multicast trees• Tree size vs. group size• When g much smaller than the number of edge

routers: power-law (Chuang and Sirbu)• When g much larger than the number of edge

routers: constant

February 3, 2009

Number of edge routers Group size (g)

Tree size (lm)

lm∼ gk

lm=lm∞

Here IP multicast is really worth the

buck

Here we explore the P2P

alternative

k ≈ 0.8…0.9


So for our backbone…• Set of measurements: • Random sources• Random groups

February 3, 2009

0 100 200 300 400 500 600 700 800 900 10000

10

20

30

40

50

60

70

80

m=1m=2m=3m=4

Number of viewers (group size)

Mul

ticas

t tre

e siz

eBetter connected

network

Worse connected network

Power-law

Saturation


Bandwidth utilizationAnalytical estimation

February 3, 2009


The problem• Input• IPTV streaming: multicast & P2P

• Random peers, preferred peers, locality optional: ρ• Watching TV: CHT, i, pi, vi

• Network topology: lu, lm • Output• Average bandwidth utilization: B• Bandwidth of one stream: B0

February 3, 2009

B=B A+BC¿ BA ,u+B A, d+BC ,m+BC , uAccess Core Access

upAccessdown

Coremcast

Coreucast


Access downstream• The easy solution:• All U users watch a TV channel

• The not so-easy solution• As an exercise: sum for all channels

February 3, 2009

BA ,d=U ⋅B0

BA ,d=∑i=1

N

bA , d(i)¿∑i=1

N

v iB0¿ B0∑i=1

N 𝒫i

T

¿B0TU ⋅T¿

B0T ∑

i=1

N 𝒫i¿B0T

𝒫∗

Does not depend on the channel

popularity

v i=𝒫i

T


Access upstream• It depends only on the channels

using P2P• g channels IP multicast / N – g channels using

P2P

February 3, 2009

BA ,u(g)= ∑i=g+1

N

bA ,u(i)¿ ∑i=g+1

N

v i , p2 pB0

≅ ∑i=g+1

N

𝜌 ⋅v i ⋅B0¿𝜌 ⋅B0T ∑

i=g+1

N 𝒫i


Core unicast• Only for TV channels that use P2P• Depending on the average path

length: lu

• Locality?February 3, 2009

BC , u(g)= ∑i=g+1

N

bC ,u(i)¿ ∑i=g+1

N

v i ⋅ lu⋅B0

¿lu⋅B0T ∑

i=g+1

N 𝒫i

BC , u(g)=B0T

[𝜌 lu , p2 p+(1−𝜌 ) lu , srv ] ∑i=g+1

N 𝒫i

Ratio of viewers using

a peer

P2P path length

Ratio of viewers using

the server

P2 server path length


Core multicast• Only for TV channels that user IP

multicast• Depending on the average tree size:

lm

February 3, 2009

BC ,m(g)=∑i=1

g

bC ,u(i)¿ B0∑i=1

g

lm (i)Depends on the group size, i.e.

channel popularity (number of viewers)


Putting everything together

NetworkPopularityOverlayLocality

February 3, 2009


Let’s sum up• The bandwidth has 4 components• Multicast channels: access downstream & core

multicast• Unicast channels: access down/up & core

unicast• Intuitive result

February 3, 2009

Number of channels using multicast (g)

Band

wid

th (B

)

Access down

Access up

Core ucast

Core mcast


Network effect• Two groups of channels: 20 popular & 80

unpopular• Choose g between 0 and 100• For every network topology (m)

February 3, 20090 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000m=1m=2m=3m=4


Tota

l ban

dwid

th

Better connected network, less

bandwidthMulticast is better, especially for non-popular channels

Q1 = 0.6

Q2 = 0.4


Network effect• Same for 3 groups of channels• 20 very popular, 30 average, 50

unpopular

February 3, 2009

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000m=1m=2m=3m=4


Tota

l ban

dwid

th

Q1 = 0.4

Q2 = 0.3

Q3 = 0.3


Popularity effect• Increase the popularity of the popular

channels• 20 popular channels, 80 unpopular channels

February 3, 2009

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000Q1=0.6Q2=0.7Q3=0.8Q4=0.9


Tota

l ban

dwid

th

Increasing popularity of

popular channels

Well well well… we don’t gain so much by using multicast


Overlay effect• For unicast channels: use a peer or use the

server?• Use a peer: scalable, distributed system• Use the server: centralized system

• Let’s play with ρ

February 3, 2009

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000

ρ=1 (only peer-to-peer)ρ=0.5


Tota

l ban

dwid

th

Using the server, we cut the upstream in the access network


Locality effect• Let’s pull the ace card for P2P: locality

• P2P cannot cut from the access upstream: we need the upstream

• P2P can cut from the distance between peers: the server is fixed!

February 3, 2009

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000λ=1 (no local-ity)λ=0.8λ=0.6λ=0.4


Tota

l ban

dwid

th

𝜆=lu , p 2plu , srv

no locality locality

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000

ρ=1 (only peer-to-peer)ρ=0.5

Number of channels using multicast (g)To

tal b

andw

idth

What we loose in the upstream for 100% P2P we can gain with a

locality factor of 0.8


Bandwidth vs. popularity• For one channel, we compare unicast and

multicast• Changing the channel popularity• We have 10000 users, 100 channels: the average

popularity is 100 users/channel

February 3, 20091 10 100 1000 10000

1E-4 1E-3 1E-2 1E-1 1E+0 1E+1 1E+2 1E+3 1E+4

0

1

2

3

4

5

6

7

8m=1m=2m=3m=4Se-ries9

Number of viewers (vi)

Unica

st to

mul

ticas

t ban

dwid

th ra

tio

Channel probability (pi)

Hot channels

Cold channels

Here: multicast

Here: we can choose

These values are for a worse P2P case!


Did we get the equations right?

Simulation results

February 3, 2009


The software• Put everything in a computer simulation

• Test the an actual P2P overlay• User behavior over time: channel holding time

• Objectives• Verify our equations (whether the averages hold)• Verify our assumptions (can ρ describe the peer

discovery decisions)• Determine realistic values for ρ and λ (locality)

• We implemented the for P2P algorithms• Random peer, with and without locality• Preferred peer, with and without locality

• Preferred peer: constraints on bandwidth, duration on the TV channel (less churn), distance from the server, etc.

February 3, 2009


Simulation data

February 3, 2009

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000Simulation: random peersSimulation: preferred peers

Number of channels using multicast

Tota

l ban

dwid

th

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000Random peers, locality-unawarePreferred peers, locality-unawarePreferred peers, locality-aware (λ≈0.85)


Tota

l ban

dwid

thWe ensure plenty

resources(each peer can server at least 2 other

peers): ρ can be high

The equations approximate well the bandwidth utilization

Although the design of the P2P overlay may

affect the locality factor we can obtain


Summing up

February 3, 2009


Multicast scalability• Scalability has been recognized and

studied• There is no natural way of consolidating multicast

entries• There are some solutions on aggregation but not

uniformly implemented• We acknowledge that scalability is only a performance

problem

February 3, 2009

0 10 20 30 40 50 60 70 80 90 1000

1000

2000

3000

4000

5000

6000

7000m=1m=2m=3m=4


Num

ber o

f mul

ticas

t ent

ries

0 10 20 30 40 50 60 70 80 90 10010000

20000

30000

40000

50000

60000

70000m=1m=2m=3m=4


Tota

l ban

dwid

thWhat we gain in terms of

bandwidth

What we loose in terms of scalability


Is there room for P2P?• In current IPTV deployments there are many

unpopular channels (few users per channel)• But their number is limited: hundreds• What happens for many more TV channels?• Third party service providers• User generated content

• Of course, a definitive answer depends on…• Will the telcos leverage their set-top boxes for this services• Cost estimation (pricing is not difficult even for multicast alone)

• We only examined bandwidth and scalability• Other considerations (delay)

February 3, 2009


Thanks

February 3, 2009

Alex Bikfalvi Jaime García-Reinoso Iván Vidal Francisco Valera Arturo Azcorra

Documents

Transcript of Alex Bikfalvi Jaime García-Reinoso Iván Vidal Francisco Valera Arturo Azcorra