reza rejaie computer and information science department university of oregon antonio ortega...
Post on 20-Dec-2015
213 views
TRANSCRIPT
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
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