240 likes | 346 Views
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. Background. heterogeneous networks. how to transmit video stream?. “One-fits-all”: no longer suited.
E N D
AdaptiveTransmission 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
Background heterogeneous networks how to transmit video stream? “One-fits-all”: no longer suited
why layered (scalable) coding? • multi-version v.s. layered coding layered-coding multi-version video two-layer video high-quality video adaptive-layer video low-quality video enable dynamic video quality adaptation!
how layered coding? • mechanism of layered coding base layer enhancement layers
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 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 the QoS of existing nodes
1、 —— improve j’s QoS • 2、RTTji is very small among all the RTTs of node i and the replying nodes —— guarantee i’s QoS Overlay Construction Phase Step 2: QoS-aware neighbor selection Step 1: Probing existing nodes poor node replacement in setp2
½ neighbors are selected to improve existing nodes’ QoS and the other ½ are selected to guarantee the new node’s QoS • Neighbor selection algorithm
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
3-Stage Model for Scheduling • Remedy Stage • k-window remedy mechanism • assume n blocks missed when the window just entered remedy stage • thus n/k blocks should be requested within each remedy window • especially important when the node encounters bandwidth burst-and-drop in the decision window
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:
3-Stage Model for Scheduling • Decision Stage (cont.) • to prevent jitter, define Jitter-Prevent-Factor (or JPF) for each layer l: • Improved Delivery Ratio, or IDR is: IDRl = DRl * JPFl • Re-calculate SP(l) with IDRl
3-Stage Model for Scheduling • Free Stage • Scheduling with Min-Cost Flow Model, to ensure high throughput • Importance Definition of the blocks • related to playback time, layer, the number of neighbors that own it
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 • Experiment results for Overlay Construction joining time recovery time benefit of node replacement
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