P V oD:Providing Fault Tolerant Video-on-Demand Streaming in Peer-to-Peer Environment
Tai T.Do,Kien A.Hua,Mounir A.Tantaoui
School of Electrical Engineering
and Computer Science
University of Central Florida
Orlando,FL32816-2362
Email:tdo,kienhua,tantaoui@cs.ucf.edu
Abstract
This paper presents a system for video-on-demand streaming in peer-to-peer environment.We start by realizing the major differences between two types of streaming:live and on-demand.These observations lead to a set of problems that need to be solved for a peer-to-peer video-on-demand system.To address these problems,we propose
a solution,which includes detail algorithms for building and maintaining an application multicast tree.The novel
service fault
ideas in this paper are the use of a new caching scheme at clients,and the introduction of generation for better client management.Performance study based on simulation is carried out.The results show that our system outperforms a recently proposed system[4]in a number of important performance metrics.
I.INTRODUCTION
We are interested in the problem of Video-on-Demand(V oD)streaming using peer-to-peer(P2P)ap-proach.Recently,there have been several research projects on live streaming using P2P approach[3,10, 11,14].However,applying these techniques into V oD streaming is not a trivial task due to the following
fundamental differences between the two types of streaming.First,end-to-end delay is more important to live streaming than V oD streaming.In live streaming,the shorter the end-to-end delay is,the more lively the stream is perceived by the users(defined as liveness in[3]).In V oD streaming,liveness is simply irrelevant because the video stream is already pre-recorded.This fact implies that while a shor
t tree rooted at the video server and spanned over clients is desirable in live streaming,it is not a necessary condition for the case of V oD streaming.Second,a user joining an on-going live streaming session is only interested in the stream starting from his/her joining time,while in the V oD streaming case the whole video must be delivered to the new user.As such,a good V oD system mustfind an efficient way to provide the initial missing part of the video to the latecomers.Moreover,the correlations between various variables are different for the two types of streaming.For example,a user will likely stop watching a V oD stream when its QoS degrades,but the user may not do the same thing for a live stream because he/she doesn’t have an option of watching it again in the future[6].Therefore,it is expected that if the QoS of the video stream reduces,many more clients will leave the system in the case of V oD streaming than in the case of live streaming.This observation stretches the importance of a quick and localized failure recovery protocol in a V oD streaming system.It is critical for one to take those differences into account in order to build a successful V oD streaming system in a P2P environment,if the proposed technique is a variant of any existing live streaming systems.
Our proposed technique in this paper is not based on any existing live streaming systems;however,the aforementioned differences are still useful for us to realize challenges in buildin
g a P2P V oD streaming system.We consider the following problems as dominant to be solved for a P2P V oD streaming system: Quick join
:Failures are expected to occur more often in a P2P system.The failure recovery protocol should reconnect the abandoned clients smoothly and quickly,so that there are no loss of frame(jitter)and no long delay(glitch)at client’s playback.In addition,the effect of the failure should be localized to ensure that minimal number of clients is affected.
Effective handling of clients’asynchronous requests
:Clients in the system may exchange information periodically or non-periodically (on-demand)to keep the system intact.The control overhead must be kept small to make the system scalable.
In this paper,we propose a P2P architecture for V oD streaming,called P V oD(Peer-to-Peer approach for V oD streaming)to solve the above problems.P V oD only assumes IP unicast at the network layer. Asynchronous requests of clients are handled by utilizing the clients’resources.Each client in P V oD has a variable-size FIFO buffer to cache the most recent content of the video stream it receives.Existing clients in P V oD can forward the video stream to a new client as long as they have enough out-bound bandwidth and still hold thefirst block of the videofile in the buffer.We introdu
ce the concept of generation and a novel caching scheme to deal effectively with failures.The caching scheme allows a group of clients,arriving to the system at different times,to share the same video content in the prefix of their buffers.Such group forms a generation.When a client(or member)in a generation leaves the system,any remaining member of that same generation can provide the video stream without jitter to the abandoned children of the leaving member provided that out-bound bandwidth is sufficient.Control information exchanged between clients is kept small,and most of the time on-demand instead of periodically.As a byproduct,our system also allows new clients to join the system fast by keeping the number of contacts a new client has to make during the join procedure small.We consider the followings as our contributions in this paper:
Introducing the concept of generation and a novel caching scheme to provide an efficient failure recov-ery protocol.
Designing an efficient application multicast tree appropriate for V oD streaming.
Proposing an efficient control protocol to facilitate the join and failure recovery processes.
There have been attempts in the research community to provide V oD service while taking advantages
of the P2P approach.However,none of these proposals provides a comprehensive or efficient protocol as P V oD.To the best of our knowledge,Chaining[1]is thefirst paper applying P2P concept in V oD streaming, but Chaining doesn’t provide a recovery protocol in case failures happen.Another proposal is DirectStream [9].DirectStream handles join and failure recovery by using a directory server.However,this centralized approach presents a single point of failures at the directory server.CoopNet[14]tries to support both live and V oD streaming.In dealing with V oD streaming,CoopNet also has several drawbacks.Clients in CoopNet may need a huge buffer to store the entire video.In case only partial of the video is found at the serving client,the requesting client has to look for the missing part from other clients,which increases the client’s startup delay.CoopNet also puts heavy control overhead on the source because the source is required to maintain full knowledge of all distribution trees.In[12],the authors assume many-to-one relationship between supplying-peer and requesting-peer,while we suppose that the relation is one-to-one in our P V oD system.That paper[12]looks at the problem of media data assignment to minimize the buffer delay,and proposes a technique to amplify the capacity of the streaming system.Perhaps,the closest work to our paper is P2Cast[4].P2Cast[4]is an extension of Patching,with the exception that a late client can get a patch not only from the server(as in original Patching)but also from other clients.Our P V oD is different from P2Cast in a couple of ways.First,clients in P V oD always cache the most rec
ent content of the video stream,while clients in P2Cast only cache the initial part of the video.Due to the caching schemes used,at any time only one stream from an early client is needed to serve a late client in P V oD,while two such streams,a patching and a base stream,are used at the beginning to deliver the video to a late client in P2Cast.Second,just like SpreadIt[10],P2Cast has to get the source involved whenever a failure occurs,thus vulnerable to disruption due to server bottleneck at the source.In addition,orphaned peers reconnect by using the join algorithm, resulting in long blocking time before their service can resume.On the contrary,in P V oD,failures are handled locally and most of the times without involvement of the source.
The rest of the paper is organized as follows.Section II presents the architecture and algorithms of the P V oD system.Performance study based on simulation is presented in section III,in which we compare
G
1
G
2
G
3
Fig.1.A snapshot of the P V oD system at time36.
P V oD to a recently proposed system called P2Cast[4].Finally,we conclude the paper in section IV.
II.A RCHITECTURE OF P V O D
A.Preliminary
In P V oD,a streaming connection is assumed to be constant bit-rate,which equals to the playback rate of the video player.We define a retrieval block(R-block)as a data unit of the video,which is also equivalent to one unit of playback time.R-blocks of a video are numbered from1to the length of the videofile according to their temporal position in the video[1].Each client has a buffer,whose maximum size is worth of units of playback time(i.e,R-blocks),to cache the most recent content of the video stream it is receiving.The actual amount of buffer storage used by a client is denoted as and lies in the range of 1.By using the cache,early arriving client can serve late coming clients by forwarding the stream.If the joining time of a client is,then can serve clients whose joining time is in the range of[,+].Clients having the same smallest numbered R-block in their caches are grouped into a generation.Generations are also numbered,starting from as the oldest generation to as the youngest generation.Clients in these generations,excluding the server,form a video session.A video session is closed when none of the clients within that video session still has thefirst R-block of the video.In this case, a new video session is needed if a new client wants to join the system.
TABLE I
N OTATIONS
Symbol
Maximum cache size of a client
Actual storage buffer used by a client
Joining time of a client
IP address of a client
The generation a client belongs to
Fig.1captures a snapshot of a video session of the P V oD system at time36.Each client can cache at most5R-blocks of the video(=5).However,the actual amount of buffer used by each client is varied. For example,client uses all available storage of the buffer(==5),while client doesn’t(
=3).When arrives to the system at time3,thefirst R-block of the video is still in the buffer of .Therefore,can serve the video stream to.Since,,,and all have the same smallest number R-block(R-block32)in their cache,they form a generation numbered as thefirst generation. For the ease of reference,we summarize the notations used throughout the paper in Table I.We also use terms such as peer,client,and user interchangeably in this paper.
B.Data Caching and Generation
Previous schemes for P2P V oD streaming do not handle failure recovery well.Usually when a failure happens,these [4])go back to the server to search for a new parent of the abandoned child. This approach has two serious drawbacks.First,it creates network contention at the server when there is a huge number of clients that need to be reconnected.Second,it increases the reconnection time resulting in unacceptable glitch at client’s playback.We overcome these limitations by using a novel caching scheme at the clients and the introduction of generation.
Formally,a generation in P VoD is a group of clients,who always have the same smallest numbered R-block in their cache.A generation is formed with the help of the caching scheme.Assume and join the same generation at time and,the caching rule is stated as following:
Caching Rule

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。