Saleable Techniques for Video on Demand Kien A. Hua School of EE & Computer Science University of Central Florida Orlando, FL 32816-2362 U.S.A.

Slides:



Advertisements
Similar presentations
1 Video Delivery Techniques. 2 Server Channels Videos are delivered to clients as a continuous stream. Server bandwidth determines the number of video.
Advertisements

Presentation of M.Sc. Thesis Work Presented by: S. M. Farhad [ P] Department of Computer Science and Engineering, BUET Supervised by: Dr. Md. Mostofa.
©Silberschatz, Korth and Sudarshan12.1Database System Concepts Chapter 12: Indexing and Hashing Basic Concepts Ordered Indices B+-Tree Index Files B-Tree.
On Large-Scale Peer-to-Peer Streaming Systems with Network Coding Chen Feng, Baochun Li Dept. of Electrical and Computer Engineering University of Toronto.
Scalable On-demand Media Streaming Anirban Mahanti Department of Computer Science University of Calgary Canada T2N 1N4.
Scalable On-demand Media Streaming with Packet Loss Recovery Anirban Mahanti Department of Computer Science University of Calgary Calgary, AB T2N 1N4 Canada.
CHAINING COSC Content Motivation Introduction Multicasting Chaining Performance Study Conclusions.
Network Coding in Peer-to-Peer Networks Presented by Chu Chun Ngai
Receiver-driven Layered Multicast S. McCanne, V. Jacobsen and M. Vetterli SIGCOMM 1996.
Web Caching Schemes1 A Survey of Web Caching Schemes for the Internet Jia Wang.
ZIGZAG A Peer-to-Peer Architecture for Media Streaming By Duc A. Tran, Kien A. Hua and Tai T. Do Appear on “Journal On Selected Areas in Communications,
An Efficient Implementation of Interactive Video-on-Demand Steven Carter and Darrell Long University of California, Santa Cruz Jehan-François Pâris University.
Internet Networking Spring 2006 Tutorial 12 Web Caching Protocols ICP, CARP.
Layered Range Multicast for Video On Demand Duc A. Tran Kien A. Hua Tai T. Do.
Analysis of Using Broadcast and Proxy for Streaming Layered Encoded Videos Wilson, Wing-Fai Poon and Kwok-Tung Lo.
Peer-to-Peer Based Multimedia Distribution Service Zhe Xiang, Qian Zhang, Wenwu Zhu, Zhensheng Zhang IEEE Transactions on Multimedia, Vol. 6, No. 2, April.
VCR-oriented Video Broadcasting for Near Video-On- Demand Services Jin B. Kwon and Heon Y. Yeon Appears in IEEE Transactions on Consumer Electronics, vol.
An adaptive video multicast scheme for varying workloads Kien A.Hua, JungHwan Oh, Khanh Vu Multimedia Systems, Springer-Verlag 2002.
An Active Buffer Management Technique for Providing Interactive Functions in Broadcast Video-on-Demand Systems Zongming Fei, Member, IEEE, Mostafa H. Ammar,
Prefix Caching assisted Periodic Broadcast for Streaming Popular Videos Yang Guo, Subhabrata Sen, and Don Towsley.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #13 Web Caching Protocols ICP, CARP.
Distributed Servers Architecture for Networked Video Services S. H. Gary Chan, Member IEEE, and Fouad Tobagi, Fellow IEEE.
An Overlay Multicast Infrastructure for Live/Stored Video Streaming Visual Communication Laboratory Department of Computer Science National Tsing Hua University.
Performance Evaluation of Peer-to-Peer Video Streaming Systems Wilson, W.F. Poon The Chinese University of Hong Kong.
A New Broadcasting Technique for An Adaptive Hybrid Data Delivery in Wireless Mobile Network Environment JungHwan Oh, Kien A. Hua, and Kiran Prabhakara.
A Hybrid Caching Strategy for Streaming Media Files Jussara M. Almeida Derek L. Eager Mary K. Vernon University of Wisconsin-Madison University of Saskatchewan.
Limiting the client bandwidth of broadcasting protocols for video on demand Jehan-Francois Paris and Darrell D.E. Long Proceedings of the Euromedia 2000.
Prof. Reza Rejaie Computer & Information Science University of Oregon Winter 2003 An Overview of Internet Multimedia Networking.
Loopback: Exploiting Collaborative Caches for Large-Scale Streaming Ewa Kusmierek, Yingfei Dong, Member, IEEE, and David H. C. Du, Fellow, IEEE.
A scalable technique for VCR-like interactions in video-on-demand applications Tantaoui, M.A.; Hua, K.A.; Sheu, S.; IEEE Proceeding of the 22nd International.
Design of an Interactive Video- on-Demand System Yiu-Wing Leung, Senior Member, IEEE, and Tony K. C. Chan IEEE Transactions on multimedia March 2003.
On-Demand Media Streaming Over the Internet Mohamed M. Hefeeda, Bharat K. Bhargava Presented by Sam Distributed Computing Systems, FTDCS Proceedings.
CS :: Fall 2003 Layered Coding and Networking Ketan Mayer-Patel.
The Split and Merge Protocol for Interactive Video-on-Demand Wanjiun Liao and Victor O.K. Li IEEE Multimedia.
CS Spring 2012 CS 414 – Multimedia Systems Design Lecture 34 – Media Server (Part 3) Klara Nahrstedt Spring 2012.
# Idowu Samuel O. # Kashif Shahzad # Arif Kamal M7001E - Multimedia systems [ltu.se] ©2011.
1 Algorithms for Bandwidth Efficient Multicast Routing in Multi-channel Multi-radio Wireless Mesh Networks Hoang Lan Nguyen and Uyen Trang Nguyen Presenter:
1 Proxy-Assisted Techniques for Delivering Continuous Multimedia Streams Lixin Gao, Zhi-Li Zhang, and Don Towsley.
Using Multimedia on the Web
Research on cloud computing application in the peer-to-peer based video-on-demand systems Speaker : 吳靖緯 MA0G rd International Workshop.
Exploring VoD in P2P Swarming Systems By Siddhartha Annapureddy, Saikat Guha, Christos Gkantsidis, Dinan Gunawardena, Pablo Rodriguez Presented by Svetlana.
Video Delivery Technologies for Large-Scale Deployment of Multimedia Applications By Hua, Tavanapong, Tanatui et. al., Univ. of Central Florida Proceedings.
COCONET: Co-Operative Cache driven Overlay NETwork for p2p VoD streaming Abhishek Bhattacharya, Zhenyu Yang & Deng Pan.
An Analysis of Chaining Protocols for Video-on-Demand J.-F. Pâris University of Houston Thomas Schwarz, S. J. Universidad Católica del Uruguay.
DELAYED CHAINING: A PRACTICAL P2P SOLUTION FOR VIDEO-ON-DEMAND Speaker : 童耀民 MA1G Authors: Paris, J.-F.Paris, J.-F. ; Amer, A. Computer.
CPSC 441: Multimedia Networking1 Outline r Scalable Streaming Techniques r Content Distribution Networks.
Streaming over Subscription Overlay Networks Department of Computer Science Iowa State University.
Live Streaming over Subscription Overlay Networks CS587x Lecture Department of Computer Science Iowa State University.
Multicast instant channel change in IPTV systems 1.
A Simple Model for Analyzing P2P Streaming Protocols Zhou Yipeng Chiu DahMing John, C.S. Lui The Chinese University of Hong Kong.
1 Push-to-Peer Video-on-Demand System. 2 Abstract Content is proactively push to peers, and persistently stored before the actual peer-to-peer transfers.
An Energy Efficient MAC Protocol for Wireless LANs, E.-S. Jung and N.H. Vaidya, INFOCOM 2002, June 2002 吳豐州.
On Reducing Mesh Delay for Peer- to-Peer Live Streaming Dongni Ren, Y.-T. Hillman Li, S.-H. Gary Chan Department of Computer Science and Engineering The.
Peer-to-Peer Media Streaming ZIGZAG - Ye Lin PROMISE – Chanjun Yang SASABE - Kung-En Lin.
NUS.SOC.CS5248 Ooi Wei Tsang 1 Proxy Caching for Streaming Media.
Unit III Bandwidth Utilization: Multiplexing and Spectrum Spreading In practical life the bandwidth available of links is limited. The proper utilization.
A simple model for analyzing P2P streaming protocols. Seminar on advanced Internet applications and systems Amit Farkash. 1.
Simulation case studies J.-F. Pâris University of Houston.
Network and Systems Laboratory nslab.ee.ntu.edu.tw Yipeng Zhou, Dah Ming Chiu, and John C.S. Lui Information Engineering Department The Chinese University.
Peer-to-Peer Video Systems: Storage Management CS587x Lecture Department of Computer Science Iowa State University.
P2P Search COP P2P Search Techniques Centralized P2P systems  e.g. Napster, Decentralized & unstructured P2P systems  e.g. Gnutella.
Large-Scale and Cost-Effective Video Services CS587x Lecture Department of Computer Science Iowa State University.
Scalable video distribution techniques Laurentiu Barza PLANETE project presentation: Sophia Antipolis 12 October 2000.
Cost-Effective Video Streaming Techniques Kien A. Hua School of EE & Computer Science University of Central Florida Orlando, FL U.S.A.
A Practical Performance Analysis of Stream Reuse Techniques in Peer-to-Peer VoD Systems Leonardo B. Pinho and Claudio L. Amorim Parallel Computing Laboratory.
The Impact of Replacement Granularity on Video Caching
Video On Demand.
Peer-to-Peer Video Services
Peer-to-Peer Streaming: An Hierarchical Approach
Scalable Video Delivery Techniques
Presentation transcript:

Saleable Techniques for Video on Demand Kien A. Hua School of EE & Computer Science University of Central Florida Orlando, FL U.S.A

Server Channels The unit of server capacity required to deliver a video stream is referred to as a channel. These channels are dispatched to deliver various video streams at different times.

Using Dedicated Streams Video Server Client Expensive Client Dedicated stream Not scalable

A Solution Using broadcast to share channels among users Broadcast is essentially “free” for a large user community

Traditional Multicast Video Server Client

Low Latency: requests must be served as soon as possible Conflicting Goals in Video Multicast ? High Efficiency: each multicast should wait to serve a larger number of clients Can we achieve both ?

Broadcast for VOD Requirement on server bandwidth is independent of the number of users the system is designed to support. Less expensive & more scalable !! Broadcast cannot deliver videos on demand ?  True  False ??

Simple Periodic Broadcast Staggered Broadcasting A new stream is started every interval for each video. The worst service latency is the broadcast period.

Limitation of Simple Periodic Broadcast Access latency can be improved only linearly with increases to the server bandwidth Double the number of channels to reduce the service latency in half Can we do better ?

Odd groupEven groupOdd group Even group Each video is fragmented into K segments, each repeatedly broadcast on a dedicated channel at the playback rate. The sizes of the K segments have the following pattern: [1, 2, 2, 5, 5, 12, 12, 25, 25, …, W, W, …, W] Skyscraper Broadcasting Size of larger segments are constrained to W (width of the “skyscraper”)

Generating Function The broadcast series is generated using the following recursive function: 1If n = 1, 2If n = 2 or 3, 2 · f(n - 1)+1If n mod 4 = 0. f(n-1)If n mod 4 = 1, 2 · f(n - 1) + 2If n mod 4 = 2, f(n – 1)If n mod 4 = 3 f(n) =

Skyscraper Broadcasting Playback Procedure The Odd Loader and the Even Loader download the odd groups and the even groups, respectively. The W-segments are downloaded sequentially using only one loader. As the loaders fill the buffer, the Video Player consumes the data in the buffer.

SB – Multiuser Example Each segment is available before it is needed for the playback Playback schedule:

Advantages of Skyscraper Broadcasting Unlimited scalability Service latency can be reduced exponentially with increases in server bandwidth Since W-segments are downloaded sequentially, buffer requirement is minimal. Skyscraper

Client Centric Approach (CCA) Segments are grouped according to the number of channels the clients can download simultaneously Inside each group, each segment is twice the size of the last segment The first segment of any group is the same size as the last segment of the previous group C = 3 (Clients have three loaders)

CCA Broadcasting Server broadcasts each segment at playback rate Clients use c loaders Each loader downloads its streams sequentially, –e.g., i th loader is responsible for segments i, i+c, i+2c, i+3c, … Equal-size W-segments are downloaded sequentially using one loader C = 3 (Clients have three loaders)

A CCA Example

Advantages of CCA It has the advantages of Skyscraper Broadcasting. It can leverage client bandwidth to improve performance.

UCF Video Jukebox

Cautious Harmonic Broadcasting (Segmentation Design) A video is partitioned into n equally-sized segments The first channel repeatedly broadcasts the first segment S 1 at the playback rate The second channel alternately broadcasts S 2 and S 3 repeatedly at half the playback rate Each of the remaining segment S i is repeatedly broadcast on its dedicated channel at 1/(i–1) the playback rate

Cautious Harmonic Broadcasting (Download & Playback Strategy) The client receives data from all streams for the video simultaneously. The client starts the playback as soon as it can download the first stream.

Cautious Harmonic Broadcasting Advantage: Better than Skyscraper Broadcasting in terms of server bandwidth requirement. Disadvantage: Requires many times more client bandwidth then Skyscraper Broadcasting does. Implementation Issues: The client must receive data from many channels simultaneously (e.g., 240 channels are required for a 2-hour video if the desired latency is 30 seconds). A storage subsystem capable of moving the read heads fast enough to multiplex among so many concurrent streams would be very expensive, if possible

Pagoda Broadcasting Data Fragmentation Each video is divided into equally-sized segments Using the following series to determine the number of segments for each channel {1, 3, 5, 15, 25, 75, 125, …} Segments appearing on a channel do not have to be consecutive 3 rd segment

Pagoda Broadcasting Download and Playback Strategy Each channel broadcasts data at the playback rate The client receives data from all channels simultaneously. It starts the playback as soon as it can download the first segment.

Pagoda Broadcasting Advantage & Disadvantage Advantage: Server bandwidth requirement is lower compared to Skyscraper Broadcasting Disadvantage: Client bandwidth requirement is many times higher than Skyscraper Broadcasting  Achieving a maximum delay of 138 seconds for a 2-hour video requires each client to have a bandwidth five times the playback rate, e.g., approximately 20 Mbps for MPEG-2  System cost is significantly more expensive

New Pagoda Broadcasting New Pagoda Broadcasting improves on the original Pagoda Broadcasting. Client bandwidth requirement remains very high Example: Achieving a maximum delay of 110 seconds for a 2-hour video requires each client to have a bandwidth five times the playback rate.  Approximately 20 Mbps for MPEG-2  System cost is very expensive

Total System Cost Service latency can be improved by increasing bandwidth in two ways: –Increasing client bandwidth, e.g., Harmonic Broadcasting, Pagoda Broadcasting, etc. This approach is expensive –Increasing server bandwidth, e.g., Skyscraper Broadcasting, CCA, etc. This approach is less expensive

Support Client Heterogeneity Using multi-resolution encoding Bandwidth Adaptor HeRO Broadcasting

Multi-resolution Encoding Encode the video data as a series of layers A user can individually mould its service to fit its capacity A user keeps adding layers until it is congested, then drops the higher layer Drawback: Compromise the display quality

Bandwidth Adaptors Advantage: All clients enjoy the same quality display

Requirements for an Adaptor An adaptor dynamically transforms a given periodic broadcast into another less demanding one The segmentation scheme must allow easy transformation of a broadcast into another CCA segmentation technique has this property

Two Segmentation Examples

Adaptation (1) Adaptor downloads from all broadcast channels simultaneously

Adaptation (2) Each sender routine retrieves data chunks from buffer, and broadcast them to the downstream For each chunk, the sender routine calls deleteChunk to decide if the chunk can be deleted from the buffer

Buffer Management insertChunk implements an As Late As Possible policy, i.e., –If another occurrence of this chunk will be available from the server before it is needed, then ignore this one, else buffer it. deleteChunk implements an As soon As Possible policy, i.e., –Determine the next time when the chunk will need to be broadcast to the downstream. –If this moment comes before the availability of the chunk at the server, then keep it in storage, else delete it.

The Adaptor Buffer Computation is not intensive. It is only performed for the first chunk of the segment, i.e., –if this initial chunk is marked for caching, so will be the rest of the segment. Same thing goes for deletion.

The start-up delay The start-up delay is the broadcast period of the first segment on the server

HeRO – Heterogeneous Receiver- Oriented Broadcasting Allows receivers of various communication capabilities to share the same periodic broadcast All receivers enjoy the same video quality Bandwidth adaptors are not used

HeRO – Data Segmentation The size of the i th segment is 2 i-1 times the size of the first segment

HeRO – Download Strategy The number of channels needed depends on the time slot of the arrival of the service request Loader i downloads segments i, i+C, i+2C, i+3C, etc. sequentially, where C is the number of loaders available. Global Period

HeRO – Regular Channels The first user can download from six channels simultaneously Request 1

HeRO – Regular Channels The second user can download from two channels simultaneously Request 2

Worst-Case for Clients with 2 loaders Worst-case latency is 11 time units The worst-cases appear because the broadcast periods coincide at the end of the global period Request 2 Coincidence of the broadcast periods  require more loaders 11 time units

Worst-Case for Clients with 3 loaders Worst-case latency is 5 time units The worst-cases appear because the broadcast periods coincide at the end of the global period Request 5 time units Coincidence of the broadcast periods

Observations of Worst-Cases For a client with a given bandwidth, the time slots it can start the video are not uniformly distributed over the global period. The non-uniformity varies over the global period depending on the degree of coincidence among the broadcast periods of various segments. The worst non-uniformity occurs at the end of each global period when the broadcast periods of all segments coincide. The non-uniformity causes long service delays for clients with less bandwidth.  We need to minimize this coincidence to improve the worst case.

We broadcast the last segment on one more channel, but with a time shift half its size. We now offer more possibilities to download the last segment; and above all, we eliminate the coincidence of all segments (i.e., no longer requiring 6 loaders). Regular Group Shifted Channel Adding one more channel

Shifted Channels To reduce service latency for less capable clients, broadcast the longest segments on a second channel with a phase offset half their size. HeRO

Under a homogeneous environment, HeRO is –competitive in service latencies compared to other protocols –the most efficient protocol to save client buffer space HeRO is the first periodic broadcast technique designed to address the heterogeneity in receiver bandwidth Less capable clients enjoy the same playback quality HeRO – Experimental Results

Hybrid Approach Periodic broadcast is better for very popular videos Batching (scheduled multicast) is more appropriate for less popular videos A hybrid of these two approaches offers the best performance

Adaptive Hybrid Approach (AHA) Popularity of each video is assessed periodically based on the distribution of recent requests. Popular videos are served using Skyscraper Broadcasting Less popular videos are served using batching Number of channels used for periodic broadcast depends on the current mix of popular videos Remaining channels are allocated to batching

Worst delay for Staggered Broadcasting Number of channels required for periodic broadcast AHA – Determine Popularity A video V i is popular if the following two conditions are true: Test 1 verifies that V i is relatively popular to deserve the periodic broadcast channels Test 2 ensures that V i is indeed popular (i.e., small inter-arrival rate)

Batching (Scheduled Multicast) Batching Scheduler Channel Pool Multicast A channel is available

AHA Schedulers Popularity Evaluator periodically assigns each video to either Batching Scheduler or Broadcast Scheduler When a request arrives for a popular video, Broadcast Scheduler informs the client which channels to download the video For less popular videos, Batching Scheduler assigns the next available channel to multicast the video with largest aggregated waiting time

We can use periodic broadcast for VOD Can we use scheduled multicast for VOD ?

Patching – First Client Regular Multicast Video A

Patching: Second Client Regular Multicast A Video Player Buffer B Video t Patching Stream Skew point

Patching: Clients Arrive at Different Times Regular Multicast A Buffer B Video 2t Skew point is absorbed by client buffer Video Player

Optimal Patching Window A r B p C p D p E r F p G p patching window W Multicast group time What is the optimal patching window ? patching window W

Simple Patching Patching is used if the client has enough buffer space to “absorb” the skew. Too greedy. May result in many long patching streams

Optimal Patching Window Compute D, the mean amount of data transmitted for each multicast group (a function of the patching period W ) Determine , the average time duration of a multicast group (a function of W ) Server bandwidth requirement is D/  which is a function of the patching period Finding the patching period W that minimizes the bandwidth requirement (D/  )

Candidates for Optimal Patching Window

Limitation of Patching Performance of Patching is limited by server bandwidth. Can we scale the application beyond the physical limitation of the server ?

Range Multicast RM Router 1 Client 1 RM Router 2 Video Server 4 Client 2 5 Client 1Client 2 6 Client 1Client 2 7 Client 1Client 2Client Client 1 Client 3Client 2 Client 3 10 Client 1Client 2 123

Range Multicast

Multicast Range All members of a conventional multicast share the same play point at all time –They must wait until the multicast time Members of a range multicast can have a range of different play points –They can join a range multicast at their leisure without waiting Multicast Range at time 11: [0, 11]

Prototype – RM Routers

Support VCR-like Operations in a Broadcast Environment ?

VCR-Like Interactivity Continuous Interactive functions –Fast forward –Fast rewind –Pause Discontinuous Interactive functions –Jump forward –Jump backward Useful for many VoD applications

VCR Interaction Using Client Buffer Video stream

Interaction Using Batching Requests arriving during a time slot form a multicast group Jump operations can be realized by switching to an appropriate multicast group Use an emergency stream if a destination multicast group does not exist Jump

Continuous Interactivity under Batching Pause: –Stop the display –Return to normal play as in Jump Fast Forward: –Fast forward the video frames in the buffer –When the buffer is exhausted, return to normal play as in Jump Fast Rewind: –Same as in fast forward, but in reverse direction

Split and Merger (SAM) Protocol Uses 2 types of streams, S streams for normal multicast and I streams for interactivity. When a user initiates an interactive operation: –Use an I channel to interact with the video –When done, use the I channel as a patching stream to join an existing multicast –Return the I channel Advantage: Unrestricted fast forward and rewind Disadvantage: I stream, used by one user, is expensive

Resuming Normal Play in SAM Use the I stream to download segments 6 and 7, and render them onto the screen At the same time, join the target multicast and cache the data, starting from segment 8, in a local buffer The user just finished the interactivity

Interaction with Broadcast Video The interactive techniques developed for Batching can also be used for Staggered Broadcast However, Staggered Broadcast does not perform well

Client Centric Approach (CCA) Server broadcasts each segment at the playback rate Clients use c loaders Each loader downloads its streams sequentially, –e.g., i th loader is responsible for segments i, i+c, i+2c, i+3c, … Equal-size W-segments are downloaded sequentially using one loader C = 3 (Clients have three loaders)

CCA is Good for Interactivity Segments in the same group are downloaded at the same time –Facilitate fast forward The last segment of a group is of the same size as the first segment of the next group –Ensure smooth continuous playback after interactivity

Broadcast-based Interactive Technique (BIT) Compression ratio is 4

BIT Two Buffers –Normal Buffer –Interactive Buffer When Interactive Buffer is exhausted, client must resume normal play

BIT Loaders: Receiving Data c+2 loaders, where c is the group size c regular loaders download the regular segments as in CCA The 2 interactive loaders function as follows: –If the current playback segment is in the first half of its group, the two interactive loaders are allocated to the previous and current interactive segments –Otherwise, they are allocated to the current and next interactive segments Keeping play point at middle of interactive buffer

BIT: Resume-Play Operation Tune to these three segments simultaneously Actual destination point is chosen from among frames at broadcast point to ensure continuous playback

BIT – Resume-Play Operation (All Scenarios) Tune to these three segments simultaneously Actual destination point is chosen from among frames at broadcast point to ensure continuous playback

BIT - User Behavior Model m x : duration of action x P x : probability to issue action x P i : probabilty to issue interaction m i : duration of the interaction m ff = m fr = m pause = m jf = m jb, P pause = P ff = P fb = P jf = P jb = P i /5. dr : m i /m p interaction ratio.

Two Performance Metrics 1.Percentage of unsuccessful action –Interaction fails if the buffer fails to accommodate the operation –e.g., a long-duration fast forward pushes the play point off the Interactive Buffer 2.Average Percentage of Completion –Measure the degree of incompleteness –e.g., if a 20-second fast forward is forced to resume normal play after 15 seconds, the Percentage of Completion is 15/20, or 75%.

BIT - Simulation Results

P2P Live Broadcast

Live Broadcast Video on Demand: Each user plays the video from the beginning Live Video Broadcast: A user joins an on-going live broadcast at the current play point of the video. ZIGZAG is a peer-to-peer technique for live broadcast

Chaining – First P2P Streaming P2P Streaming is another way to scale beyond the bandwidth limitation of the server Video Server disk Screen disk Screen disk Client A Client B Client C

Requirements in P2P Live Broadcast Low Overhead High Liveness Robustness

Liveness & Load Balancing Server I am overloaded Is it too far? new I want to join fast

Robustness Server The server is already busy Too many reconnections!

Control Overhead Peers periodically exchange information to maintain its position and connections. The overhead of this task should be small and independent of the number of peers

ZIGZAG Live Broadcast A peer, at its highest level, connects to peers from a different cluster in the next level Peers that are not leaders get data from a leader of a different cluster

ZIGZAG - Advantages Short broadcast tree improves liveness Small fanout keeps reconnecting cost low Hierarchy helps reduce control message overhead

Pull-based P2P Streaming  Join the network as a new peer  Obtain information of desired data through a gossip- based mechanism  Pull data from different peers

Pull vs Push Push –Peers at the edges of the multicast structures do not contribute resources Pull –A lot of redundant data in the network –Searching for data (gossiping or using DHT) incurs overhead

Many P2P Streaming Systems on Internet PPLive PopCast PPStream Coolstreaming TV Ants QQLive 96

2-Phase Service Model (2PSM) Browsing Video in a Low Bandwidth Environment

Search Model 1.Use similarity matching or keyword search to look for the candidate videos. 2.Preview some of the candidates to identify the desired video. 3.Apply VCR-style functions to search for the video segments.

Conventional Streaming Advantage: Reduce wait time 1. Download S o 2. Download S 1 while playing S Download S 2 while playing S 1... Disadvantage: Not suitable for searching video

Search Techniques Use extra preview files to support the preview function  Requires more storage space  Downloading the preview file adds delay Use separate fast-forward and fast- reverse files to provide VCR-style operations  Requires more storage space  Server can become a bottleneck

VCR-like Functionality is Expensive Supporting VCR-like operations demands substantial network bandwidth, and requires significant server resources Can we avoid these costs ?

2PSM – Preview Phase

2PSM – Playback Phase t

Advantages 1. It requires no extra files to provide the preview feature. 2. Downloading the preview frames is free. 3. It requires no extra files to support the VCR functionality. 4. Server is not involved in the VCR-style interaction.

–UCF Video Browser

iSEE - Intelligent Sensors Exploration Environment