280 likes | 403 Views
Push-to-Peer Video-on-Demand System. Abstract. Content is proactively push to peers, and persistently stored before the actual peer-to-peer transfers. Content placement and associated pull policies that allow optimal use of uplink bandwidth.
E N D
Abstract • Content is proactively push to peers, and persistently stored before the actual peer-to-peer transfers. • Content placement and associated pull policies that allow optimal use of uplink bandwidth. • Performance analysis of such policies in controlled environments such ad DSL networks under ISP control. • A distributed load balancing strategy for selection of serving peers.
Outline • Introduction • Network Setting and Push-to Peer Operation • Data Placement and Pull Policies • Randomized Job Placement • Conclusion
Introduction • Pull-based system design: a peer pulls content only if the content is of interest. • Our objective is to design a Push-to-Peer VoD System. • Video is first pushed to peers. • This first step is performed under provider or content-owner control, can be performed during times of low network utilization. • A peer may store content that it itself has not interest in, unlike traditional pull-only P2P system.
Introduction • This system is applicable to cases in which peers are long-lived and willing to have content proactively pushed to them. • We consider the design: • In a network of long-lived peers where upstream bandwidth. • Peer storage are the primary limiting resources. • Constant available bandwidth among the peers.
Network Setting and Push-to Peer Operation • Describe the network setting for this system. • Overview the push and pull phases of operation. • Describe our video playback model.
Three Components • The Push-to-Peer system comprises a content server, a control server and boxes at the user premises (STBs). • User Premise: STBs, coutomers. • Content Server: • located in the content provider’s premise, • push content to boxes. • Control Server: • located in the content provider’s premise, • provides a directory service to boxes, • management and control functionalities.
Two Phases • Content distribution proceeds in two phase: • Push Phase: • Content server push content to each boxes, • This occurring periodically: • when bandwidth is plentiful, • in background, low priority mode. • After push content, content server then disconnect, does not provide additional content. • What portions of which videos should be placed on which boxes?
Two Phases • Pull Phase: • Boxes respond to user command to play content. • Boxes don’t have all of the needed content at the end of the push phase. • We don’t consider the possibility of the boxes proactively push content among themselves.
Assumption • Assumption about DSL network and the boxes. • Upstream and downstream bandwidth • Peer storage • Peer homogeneity
Upstream and downstream bandwidth • The upstream bandwidth is a constrained resource, most likely smaller than the video encoding, playback rate. • When a peer uploads video to N different peers, the upstream bandwidth is equally shared among those peers. • Video is transferred reliably. • Downstream bandwidth is sufficiently large that it is never the bottleneck when download video. • The downstream bandwidth is larger than the video encoding, playback rate.
Peer storage • Boxes have hard-disk that can store content. • The disk may also store movie prefixes, that are used to decrease startup delay. • We don’t consider the play-out buffer.
Peer homogeneity • All peers have the same upstream bandwidth and the same amount of hard disk storage.
Video Playback Model • Each movie is chopped into windows of contiguous data of size W. • A full window needs to be available to the user before it can be played. • A user can play such a window once it is available, without waiting for subsequent data. • The window size is tunable parameter. • The window is a unit of random access to a video. • The window allows us to support VCR optionatios. • Each window is further divide into smaller data block.
Video Playback Model • Blocking Model: when a new request cannot be served, the request is dropped. • Waiting Model: the request is enqueued.
Data Placement and Pull Policies • Full-Striping Data Placement • Code-Based Data Placement • We assume that there M boxes. • Each window of a video is W.
Full-Striping Data Placement • Stripes each window of a movie over all M boxes. • Every window is divided into M blocks, each of size is W/M. • Each block is pushed to only one box. • Each box stores a distinct block of a window. • A full window is reconstructed at a box by concurrently downloading M-1 distinct blocks from the other M-1 boxes. • A download request generates M-1 sub-request.
Sub-Request Limited • The number of sub-requests that a box can serve simultaneously. • Renc: video encoding, playback rate. • Renc/M: receive blocks from each of the M-1 target boxes. • We should limit the Kmax distinct sub-request: • Kmax = BupM / Renc
Code-Based Data Placement • A box can serve is bounded by y, and y < M-1. • This scheme applies rateless coding. • This scheme divides each window into k source symbols, and generate • Ck = (M * (1 + e) / (y + 1)) / k coded symbols. • C is the expansion ratio, and C > 1. • For each window, the Ck symbols are evenly distributed to all M boxes such that each box keeps Ck/M distinct symbols. • A viewer can reconstruct a window of a movie by concurrently download any Cky/M distinct symbols from an arbitrary set of y boxes. • Unlike full striping, only y boxes are needed to download the video.
Randomized Job Placement • The decision where to place and serve the sub-request of a job. • Propose a distributed load balance strategy for the selection of serving peers. • The strategy we consider for initial job placement is as follow:
Randomized Job Placement • When a download request is generated, d distinct boxes are randomly chosen from the overall M boxes. • The load, measured in terms of fair bandwidth share that a new job would get, is measured on all probed boxes. • Finally, sub-request are placed on the y least loaded boxes among the d probed boxes. • Provided the each of the y sub-request gets a sufficiently large fair bandwidth share. • If any of the loaded boxes cannot guarantee such a fair share, then the request is dropped.
Conclusion • We proposed a P2P approach, and show the theoretical upper performance bounds that are achieved if all resource of all peers are perfectly pooled. • However, perfect pooling in practice is not feasible. • Therefore, we proposed a randomized job placement algorithm. • We plan to do a more systematic analysis of placement schemes that take into account movie popularity.