Reza RejaieComputer and Information Science Department

University of Oregon

Antonio OrtegaIntegrated Media Systems CenterUniversity of Southern California

NOSSDAV 2003 Monterey, California

6/3/2003

PALS: Peer-to-Peer Adaptive Layers Streaming

Motivation

Peer-to-Peer (P2P) networks emerge as a new communication paradigm that improves:• Scalability, robustness, load balancing, etc• Research on P2P network has mostly focused

locating a desired content, not on delivery

Audio/Video streaming applications are becoming increasingly popular over P2P network• “streaming” a desired content to a peer rather

than swapping files, e.g. sharing family videos. How can we support streaming applications

in P2P networks?

Streaming in P2P Networks

Each peer might have limited resources• Limited uplink bandwidth or processing power

Several peers should collectively stream a requested content, this could achieve:• Higher available bandwidth, thus higher

delivered quality • Better load balancing among peers• Less congestion across the network• More robust to peer dynamics

But streaming from multiple peers presents several challenges …

Challenges

How to coordinate delivery among multiple senders?How to cope with unpredictable variations in available bandwidth?How to cope with dynamics of peer participation?Which subset of peers can provide max. throughput, thus max. quality?

P2P Adaptive Layer Streaming (PALS)

PALS is a receiver-driven framework for adaptive streaming from multiple senders• All the machinery is implemented at receiver

Using layered representation for streams

Applicable to any multi-sender scenario

Justifying Main Design Choices

Why receiver-driven?• Receiver is a permanent member of the session• Receiver has knowledge about delivered packets• Receiver knows current subset of active senders• Receiver observes each sender’s bandwidth• Minimum load on senders => more incentive!• Minimum coordination overhead!

Why layered representation for stream?• Both MD and layered encoding should work• Efficiency vs robustness• PALS currently uses layered encoded stream

Assumptions & Goals

Assumptions:All peers/flows are cong. controlled Content is layered encodedAll layers are CBR with the same BW*All senders have all layers*List of senders is given

* Not requirements

Goals:To maximize delivered quality• Deliver max no of

layers• Minimize variations in

quality

Basic Framework

Receiver: periodically requests an ordered list of packets from each sender.Sender: simply delivers requested packets with the given order at the CC rateBenefits of ordering the requested list: • Receiver can better control delivered packets• Graceful degradation in quality when bw suddenly

drops

Periodic requests => less network overhead

Basic Framework

Internet

Peer 0bw

(t)2

bw (t)1

CCCbuf1

buf2

bw (t)3

3buf

Decoder

Demux

Cbuf0

bw (t)0

BW0BW1

BW2

Peer 1

Peer

2

Receiver keeps track of EWMA BW from each sender

EWMA overall throughput

estimate total no of pkts to be delivered during a period (K)

Allocate K pkts among active layers (Quality Adaptation)

• Controlling bw0(t), bw1(t), …,

Assign a subset of pkts to each sender (Packet assignment)

•Allocating each sender’s bw among active layers

Keep senders sync. with receiver

Key Components of PALS

Quality adaptation (QA): to determine quality of delivered stream, i.e. required packets for all layers during each intervalSliding Window (SW): to keep all senders synchronized with the receiver & busyPacket Assignment (PA): to properly distribute required packets among sendersPeer Selection (PS): to identify a subset of peers that provide maximum throughout

We present sample mechanisms for QA, SW and PA.

Quality Adaptation

Same design philosophy as unicast QA but different approach:• Receiver-based

• Delay in the control loop

• Multiple senders• Periodic adaptation, rather

than on per-packet basis

Two degrees of control• Add/drop top layer(s)• Adjust inter-layer bandwidth

distribution

bw (t)2

bw (t)1

CCCbuf1

buf2

bw (t)3

3buf

Decoder

Demux

Cbuf0

bw (t)0

Fillingphase

Drainingphase

t

BW

ave bw

str bw

Quality Adaptation (cont’d)

The goal is to control buffer state: • Total amount of buffered data• Distribution of buffered data among active layers

Controlling evolution of buffer state by regulating inter-layer bandwidth allocation (bw0, bw1, ..)Efficient buffer state:• min no of buffering layers with skewed distribution

Efficient buffer state depends on the pattern of variations in bandwidth which is unknown at receiverAlternative solutions:• Use measurement to derive the pattern• Assume a fix target buffer dist., e.g. buf(i) = n*buf(i+1)

Quality Adaptation (cont’d)

Run QA algorithm periodically, to plan for one period,• Assume EWMA BW remains fix and

estimate no of incoming packets• Determine fill/drain phase, and no of

layers to keep

Filling Phase: 1) Sequentially, fill up layers up to next

target buffer state with n layers2) Sequentially, fill up layers up to the

target buffer state with n+1 layers3) Add a new layer, go to Step 1.

Drain Phase:1) Sequentially, drain layers down to

previous target buffer state2) Drop the top layer, go to Step 1

bw (t)2

bw (t)1

CCCbuf1

buf2

bw (t)3

3buf

Decoder

Demux

Cbuf0

bw (t)0

Sliding Window

Keep senders loosely synchronized with receiver’s playout time: • Sliding window, send a new request to each

sender per window• Overwriting, a new request overwrites old one

timetp

L0

D

L1

L2

tmin

Period

Playout time

Sliding Window (cont’d)

Window size controls the tradeoff between responsiveness vs control overhead. • Should be a function of RTT. • Difficult to manage senders with major diff in RTT

Keep senders busy when BW is underestimated.• Reverse Flow Control (RFC): send a new request to a sender before it

runs out of packets

How should QA mechanism be coupled with the receiver’s requests to different senders?

Coupling QA & SW

Synchronized Requesting• Send new requests to all senders simultaneously

when slides the window forward+ QA uses overall BW, rather than per-sender BW- fast sender becomes idle or overwriting slow

senders- hard to manage senders with major difference in

RTT.

Asynchronous Requesting• Send a new request to a sender when RFC signals+ Effectively manages different senders separately- Requires different approach to QA, i.e. QA should

factor in individual BW

Packet Assignment

Given a pool of required packets in one interval, how to assign packets to senders?• Number of assigned packets to a sender

depends on its BW• Need to cope with sudden decrease in BW

• Order each requested list based on importance of packets

How to order all packets? How to divide them among senders?

Packet Assignment (cont’d)

Criteria for ordering packets, e.g. lower layers or lower playout time.Weighted round robin packet assignment

Ideal pattern efficient pattern

Preliminary Evaluation

Synchronized requestingConfigurations• 3 PAL senders over RAP

connections with diff RTT• 10 TCP background flows• window size = 4 * SRTT

spal2

spal1

spal0

spal0

20ms5 Mb

10 TCP5ms10 Mb

15ms10 Mb

25ms10 Mb

Scenario I

Scenario II

Related Work

Streaming from multiple senders• MD [Apostolopoulos et al.]• CC streaming [Nguyen et al.]

Streaming in P2P networks: form distribution trees from peers• CoopNet [Padmanabhan et al.]• Existing systems, e.g. Abacast, chaincast,…

Structuring a distribution tree• e.g. Zigzag [Tran et al.]

Other receiver-driven adaptation,• RLM [McCanne et al.]

Conclusion & Future Work

PALS, a receiver-driven framework for streaming from multiple senders• Receiver-based QA from multiple senders• Keeping sender loosely synchronized• Distributing load/packets among senders

Future work• Extensive simulation, to obtain deeper

understanding of the dynamics in PALS• Measurement-based derivation of BW variations• Peer selection mechanism• Effect of peer dynamics• Supporting VBR streams and MD encoding

Reza RejaieCIS Department,

University of Oregon

Antonio OrtegaIntegrated Media Systems CenterUniversity of Southern California

PALS: Peer-to-Peer Adaptive Layers Streaming