adaptive overlay topology for meshmesh--based p2p based

Adaptive Overlay Topology for Adaptive Overlay Topology for MeshMesh--Based P2PBased P2P--TV SystemsTV Systems

Richard Lobb (Univ. Canterbury, NZ)

Ana Paula Couto da Silva (Univ. Juiz de Fora, BR)

Michela Meo – NOSSDAV 2009

Ana Paula Couto da Silva (Univ. Juiz de Fora, BR)

Emilio LeonardiMarco MelliaMichela Meo

Politecnico di Torino, Italy

MeshMesh--BasedBased P2PP2P--TV TV SystemsSystems

• Distribute TV channels over the Internet in a P2P fashion

• Video is generated by a source and


• Video is generated by a source and received by users with short delay

• The video information is organized in small chunks that are individually and independently distributed by the participating peers


IP network

Overlay

Chunk 1 distribution

time


distributiontree

Chunk 2 distribution

tree

Chunk distribution processChunk distribution process

• Each peer maintains a (small) transmission window with chunks to be redistributed to other peersother peers

• A scheduling process decides which chunk to distribute to which neighboring peer

• The most critical phase of the chunk distribution is the initial one (when it is rare)


After a delayChunkSize/Bw1

1 more peer can contribute

P1


Q1


Q1

After a delay ChunkSize/Bw1

1 more peer can contribute

P1


Q1


After the same delayChunkSize/Bw1

3 more peers can contribute

P2P2 has 3 times the Bw of P1

Q1

Q1

Q2 Q3

Upload Upload bandwidthbandwidth matters…matters…

• Peers that can contribute more to the chunkdistribution (high bw peers) should be

�favored during the scheduling process�favored during the scheduling process


Upload Upload bandwidthbandwidth matters…matters…

• Peers that can contribute more to the chunkdistribution (high bw peers) should be

�favored during the scheduling process�favored during the scheduling process


High bw peers should bepreferentially served first

SchedulingScheduling isis notnot enoughenough

• Peers that can contribute more to the chunkdistribution (high bw peers) should also

�Have many neighbors (they can use their bw)

High bw, small out-degree:Too few neighbors to distribute the

chunk to, the bw is not well exploited

�Have many neighbors (they can use their bw)

�Be close to the source

�Be well connected to each other, to speed up the distribution between high bw peers


Low bw, large out-degree:Large neighborhood is useless for

distribution (little bw), while it is costly to manage

SchedulingScheduling isis notnot enoughenough

• Peers that can contribute more to the chunkdistribution (high bw peers) should also

�Have many neighbors (they can use their bw)�Have many neighbors (they can use their bw)

�Be close to the source

�Be well connected to each other, to speed up the distribution between high bw peers


Overlay construction and maintenance are

crucial

Our proposal key pointsOur proposal key points

• Overlay maintenance algorithm that

�Automatically adapts the out-degree (neighborhood size) to the actual capacity of (neighborhood size) to the actual capacity of the peer to contribute to chunk distribution

�Automatically makes high bw peers highly connected and close to the source

�Does not require the explicit estimation of peer bw


Set a time window

Every time window……compute the fraction of used links

Use this value as an indication of peer capacity


• Large? (the peer can contribute more)

Increase out-degree

• Small? (the neighborhood is too large)

Decrease out-degree

Use this value as an indication of peer capacityto contribute to chunk distribution

Set a time window.

Every time window……compute the fraction of used links

Use this value as an indication of peer capacity

Control the no. of unused links


• Large? (the peer can contribute more)

Increase neighborhood

• Small? (the neighborhood is too large)

Decrease neighborhood

Use this value as an indication of peer capacityto contribute

UUU HL αα <<

no. of used links no. of unused links

Control the no. of unused links

Implicit estimation of bandwidthImplicit estimation of bandwidth

• Fraction of used links is employed to adapt the out-degree to the capacity of the peer to contribute the peer to contribute

• The peer out-degree is then used as an implicit estimation of its bandwidth

�For scheduling

�When choosing/dropping peers


Growing the neighborhoodGrowing the neighborhood

• New peers are added choosing among the set of neighbors’ neighbors

• Within this set, peers are chosen with a probability proportional to the desirability

• Within this set, peers are chosen with a probability proportional to the desirability function

�The desirability function is monotonic increasing with out-degree

�Out-degree is thus used as an implicit measure of the peer upload bandwidth


Need to exchange the list of neighbors and

their out-degree

Growing the neighborhoodGrowing the neighborhood

• At peer p, neighborhood size L(p) increases by

� kL(p): k is the growth factor

• Initially, L(p) is small • Initially, L(p) is small

�Low bw peers are not congested

• Initially, k=ki

k linearly decreases to kf < ki

�High bw peers quickly grow their neighborhood


Shrinking the neighborhoodShrinking the neighborhood

• Cull from the neighborhood a number of links within the set of unused links, so that

• Set UU HL αα +=• Set


UU2

=

no. of desired unused links

UUU HL αα <<

no. of unused links no. of used links

Chunk schedulerChunk scheduler

• Choose the latest useful chunk (latest chunk needed by some neighbor)

• Send chunk to neighbor q with probability • Send chunk to neighbor q with probability proportional to the desirability function


∑∈

=

),(

)(

)()(

pcNr

rDqD

qp

desirability function

)()( qLqD =

set of neighbors needing the chunk

Scenario & evaluationScenario & evaluation

• Discrete event simulator

Download P2PTVSim from www.napa-wine.eu

• 10,000 chunks (1000s at 10 chunk/s rate)• 10,000 chunks (1000s at 10 chunk/s rate)

• N=10,000 peers, partitioned in 4 classes

� Class 1 (10%): Bw=5Mbps


� Class 3 (40%): Bw=0.5Mbps



E[Bw]=1.1Mbps(video rate=1Mbps)

Other parametersOther parameters

• Chunk size 0.1Mb, 10 chunks/s

• Playout delay=5s (50 chunks)

• Start with L(p)=10• Start with L(p)=10

• Time window size: 50 chunks

• ki=0.4, kf=0.1, after 750 chunks

• aL=0.1, aH=0.3


THE ADAPTIVE OVERLAYTHE ADAPTIVE OVERLAY


degr

ee

80

100

120

140

Bw=5Mbps

NeighborhoodNeighborhood


Out

-degr

ee

Chunk0 2000 4000 6000 8000 10000

20

40

60

Bw=1Mbps

short adaptationtime (2 min)

NeighborhoodNeighborhood

Per class: percentage of links to other classes


Peers prefer to be connected to high bw peers (10% of total only)

PERFORMANCEPERFORMANCE


DelayDelay

0.8

1.0

1.2


High bw peers are favored

Chunk

Dela

y

0 500 1000 1500 2000 2500 30000

0.2

0.4

0.6

LossesLosses

600

800

1000of

loss

es


0

200

400

0 50 100 150 200 250 300

Num

ber

Chunk

Only during the initial transient

ImprovementImprovementDela

y[s

]

1.0

1.5

High bw peers - more neigh.- highly connected


Dela

y

Degree, k10 20 30 40 50 60 70 80 90 100

0

0.5

Tot no. links smaller of a

factor 4

ChurningChurning

60

70

80

• 50% of the peers disconnect after a random time in [10,100]s

Robust to churning


Degr

ee

Chunk0 2000 4000 6000 8000 10,000

10

20

30

40

50

60

ChurningChurning

0.8

1.0


Chunk

Dela

y

0 500 1000 1500 2000 2500 30000

0.2

0.4

0.6

ConclusionsConclusions

• Effective in adapting the overlay to peer heterogeneity

� Neighborhood size and topology

• Robust to varying conditions •� Churning

� Available bw variations

• Simple and does not need bw estimation

• Requires limited exchange of information

� List of neighbors and their out-degree


Impact Impact ofof loadload

dela

y

6

7

8

9

10Loss, dmax=5Delay, dmax=5Loss, dmax=10Delay, dmax=10


00.9 1.0 1.05

Los

ses/

dela

y

Load0.95 1.1

1

2

3

4

5

6

Sensitivity to parametersSensitivity to parameters

ααααH


ααααL

Delay decreases with large no. unused links

adaptive overlay topology for meshmesh--based p2p based

Documents