adaptive transmission for layered streaming in heterogeneous peer-to-peer networks

Adaptive Transmission for layered streaming in heterogeneous

Peer-to-Peer networks Xin Xiao, Yuanchun Shi, Yuan Gao

Dept. of CS&T, Tsinghua University

Beijing, China

2008.10.13

Backgroundheterogeneous networks

how to transmit video stream?

“One-fits-all”: no longer suited

why layered (scalable) coding?

multi-version v.s. layered coding

high-quality video

multi-version video

low-quality video

enable dynamic video quality adaptation!

two-layer video

adaptive-layer video

layered-coding

how layered coding?

mechanism of layered coding

base layer

enhancement layers

Lay

ered

Cod

er

Layer 2

Layer 3

Layer 1

D

D

D56kb/s

256kb/s

1Mb/s

what is our work?

in an heterogeneous peer-to-peer network to adaptively transmit layered streaming to a large

number of users

the goal is divided into two parts high performance overlay construction

i.e. the newly joined node how to select neighbors optimal data scheduling

i.e. how to request and relay data

Toward High Performance Overlay Construction for Layered Streaming

what’s characteristics of overlay construction for layered streaming?

1 、 connection condition is not the unique criterion for QoS

2 、 greedy neighbor selection is apt to construct poorer overlay

A better neighbor choice!

B

G

A

C

Existing node

Newly joining node

Legend

LAN

300Kbps

250Kbps

1M

1M

1M

600Kbps

If each layer’ s bitrate is 300K, selecting node G can get 2 layers!

600Kbps

600Kbps

B

D

A

C

Existing good node

Newly joining node

Legend700K

1M

1M

1M1M

1M

1M

F

H

G

E

200K

100K

250K

700K

500KExisting

poor node

suppose the maximum allowed neighbor number for new node is 3

D

Overlay Construction Phase

Key idea network condition and providing layers as a whole

rather than selecting neighbors just according to their network conditions

should probe and find appropriate logical partners for each layer

avoidance of greedy neighbor selection guarantee the QoS of new node as well as improve th

e QoS of existing nodes

Overlay Construction Phase

j

i

kselects j as neighbor

probes newneighbor

_ _ ( ) jlink num of j m

*min( )ji jRTT RTT&&

Nl

p2

p3

i

p1

1. probes Nl

2. Nl replies{(p1,RTT(Nl,p1)),(p2,RTT(Nl,p2)),(p3,RTT(Nl,p3))}

3. probes p1, p2 and p3

……

……

j

i

Step 1: Probing existing nodes

Step 2: QoS-aware neighbor selection

1 、 —— improve j’s QoS2 、 RTTji is very small among all the RTTs of node i and the replying nodes —— guarantee i’s QoS

*( )ji jRTT E RTT

poor node replacement in setp2

Neighbor selection algorithm

½ neighbors are selected to improve existing nodes’ QoS and the other ½ are selected to guarantee the new node’s QoS

Toward Optimal Data Scheduling for Layered Streaming

Four goals for data scheduling

Unlike non-layered streaming where the optimization objective is almost equal

to maximizing the throughput and/or minimizing the packet delay

Goals for layered streaming Throughput and Delay Layer Delivery Ratio Useless Packet Ratio Jitter Prevention

3-Stage Model for Scheduling

Node’s buffer is divided into 3 stages

Free Stage free request data, to guarantee throughput

Decision Stage decide on subscribing layers, to ensure delivery ratio,

useless packets ratio. Jitter prevention is also considered Remedy Stage

re-fetch the missed minor blocks within the subscribed layers

current playback blocks

remedy stagedecision

stagefree stage

Block ID

Layer ID

buffering windows

34 4

6 65

4

read-only buffer

3-Stage Model for Scheduling

Remedy Stage k-window remedy mechanism assume n blocks missed when the window just entered r

emedy stage thus n/k blocks should be requested within each remedy

window especially important when the node encounters bandwidt

h burst-and-drop in the decision window

current playback blocks

remedy stagedecision

stagefree stage

Block ID

Layer ID

buffering windows

34 4

6 65

4

read-only buffer

3-Stage Model for Scheduling

Decision Stage probability decision mechanism assume when the window just enters decision stage

the missed blocks number is ml in layer l

the neighbors can supply sl (under bandwidth constraint)

thus delivery ratio of layer l is: DRl = 1 – (ml - sl) / wnd_blocksl subscription probability is:

current playback blocks

remedy stagedecision

stagefree stage

Block ID

Layer ID

buffering windows

34 4

6 65

4

read-only buffer

1, ( )

/ ,l std

l std

if DR ratioSP l

DR ratio otherwise

3-Stage Model for Scheduling

Decision Stage (cont.) to prevent jitter, define Jitter-Prevent-Factor (or JPF) for each l

ayer l:

Improved Delivery Ratio, or IDR is: IDRl = DRl * JPFl

Re-calculate SP(l) with IDRl

current playback blocks

remedy stagedecision

stagefree stage

Block ID

Layer ID

buffering windows

34 4

6 65

4

read-only buffer

1, ( )

/ ,l std

l std

if IDR ratioSP l

IDR ratio otherwise

*lastHL l

K LlJPF e

3-Stage Model for Scheduling

Free Stage Scheduling with Min-Cost Flow Mod

el, to ensure high throughput Importance Definition of the blocks

related to playback time, layer, the number of neighbors that own it

current playback blocks

remedy stagedecision

stagefree stage

Block ID

Layer ID

buffering windows

34 4

6 65

4

read-only buffer

Implementation

In NS-2 simulator test our approach in comparison with others the underlying link-layer topology is generated by

GT-ITM On Internet

we have been developing real system with support of ACE (Adaptive Communication

Environment) SDK—C++, platform independent with PFGS layered encoding

Evaluation

Experiment results for Overlay Construction on throughput, delay, in comparison with

SCAMP ： based on Gossip ， random neighbor selection

Narada ： based on QoS selection

Evaluation

joining time recovery time benefit of node replacement

Experiment results for Overlay Construction

Evaluation

Experiment results for Data Scheduling on the above four goals, with PALS, Chainsaw and Pure-MCFP

Evaluation

Experiment results for Data Scheduling on the impact of remedy window number k, and ratiostd

Implementation In Real Network

The PFGS-based layered streaming

Recovered with base layer Recovered with base & enhancement layers

Implementation In Real Network Deployment in the PDEPS (Project of Digital

Education for Public Service) project to deliver live teaching broadcast to users with

heterogeneous networks the first practical layered streaming system for

education in peer-to-peer network

run on PC run on PDA