P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in ...
Upcoming SlideShare
Loading in...5

P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in ...






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in ... P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in ... Presentation Transcript

  • P2VoD: Providing Fault Tolerant Video-on-Demand Streaming in Peer-to-Peer Environment Tai T.Do, Kien A. Hua, Mounir A. Tantaoui Proc. of the IEEE Int. Conf. on Communications (ICC 2004)
  • Outline
    • Introduction
    • Related Work
    • Architecture of P2VoD
    • Performance Evaluation
    • Conclusion
  • Introduction
    • P2P approach can potentially solve many serious problems posed in existing streaming systems
      • Infeasibility of IP Multicast
      • Network bottleneck at the video server
    • Several projects on “live streaming”
      • Not trivial to apply these techniques into VoD systems
  • Introduction (cont.)
    • Live streaming
      • Shorter end-to-end delay, more lively the stream
      • Short tree rooted at the video server
      • User simply joins an on-going live streaming session
      • User may not quit if QoS degrades
    • VoD streaming
      • Liveness is irrelevant, video is pre-recorded
      • Whole video must be delivered
      • User will stop watching if QoS degrades
  • Introduction (cont.)
    • Proposed techniques not based on any existing live streaming systems
    • Problems to be solved for a P2P VoD streaming system
      • Fast and localized failure recovery without jitter
      • Quick join
      • Effective handling of clients’ asynchronous requests
      • Small control overhead
    • P2VoD (Peer-to-Peer approach for VoD streaming)
  • Related Work: P2Cast
    • Architecture uses a P2P approach to stream video using patching
    • Build application level multicast tree
      • Server streams the entire video over base tree
    • P2Cast clients provide two functions
      • Base stream forwarding
      • Patch serving
    • Base tree construction & patch server selection algorithm
      • Best Fit (BF): find the “fattest pipes” to requesting clients
      • BF-delay: also use network delay information
      • BF-delay-approx: not using actual available bandwidth, (1 or 0 represents enough bandwidth or not)
  • Architecture of P2VoD
    • A streaming connection is assumed to constant bit-rate
      • equals to the playback rate of the video
    • Retrieval block (R-block) as a data unit of the video
      • equivalent to one unit of playback time
    • Each client has a buffer, whose maximum size is worth of MB units of playback time (i.e. MB R-block)
  • Architecture of P2VoD (cont.)
    • ab X : actual amount of buffer storage used by a client X
      • 1 ≤ ab X ≤ MB
    • By using the cache, early arriving client can serve late coming clients by forwarding the stream
      • tj X : the joining time of a client X
      • X can serve clients whose joining time
        • [ tj X , tj X + ab X ]
  • P2VoD system
    • ab C 1 = MB = 5, ab C 4 = 3 < MB
    • When C 6 arrives to the system at time 3, the first R-block of the video is still in the buffer of C 1
    • C 1 can serve the video stream to C 6
  • Architecture of P2VoD (cont.)
    • “ Generation”
      • Group of clients having the same smallest numbered R-block in their caches
    • Generations are also numbered
      • G1 as the oldest generation to Gn as the youngest generation
    • Clients in these generations, excluding the server, form a video session
      • A video session is closed
        • none of the clients has the first R-block of the video
  • P2VoD system
    • C 1 , C 2 , C 3 , C 4 , and C 5 all have the same smallest number R-block
  • Data Caching and Generation (cont.)
    • Rules to build generations
      • Generations are indexed by numbers starting from 1
      • Members of a lower indexed generation arrive to the system no latter than any member of other higher indexed generations
      • A peer in generation i-th (i > 1) receives the video stream from a peer in generation (i – 1)-th
        • Peers at the first generation receive the video stream directly from the server
      • When joining a video session of the system, a new peer
        • belongs to the current highest numbered generation, OR
        • be the first member of a newly created generation of that video session
  • Data Caching and Generation (cont.)
    • Caching scheme with the generation concept
    • X and Y join the same generation at time tj X and tj Y
      • Caching Rule: The difference of actual cache sizes used by two peers in the same generation must offset the difference in their arrival times
      • ab X – ab Y = tj Y – tj X
    • E.g . ab C 2 = ab C 1 – ( tj C 2 – tj C 1 )
      • = 5 – (1 - 0) = 4
  • Data Caching and Generation (cont.)
    • Assume that at time 36, peer C 3 fails.
    • C 1 , C 2 , C 4 , C 5 available to C 8
    • allow a quick and localized recovery for C 8
  • Control Protocol
    • Control Protocol is required to maintain the system connectivity
    • Neighbors of peer X
      • Siblings (peer in same G): need to keep a list of their IP addresses
        • Periodically update the list
        • Update the list on-demand (joining/leaving)
      • Child: agree to forward the video stream, X needs to send the IP addresses of X and its siblings to its child
      • Parent: first join the system, X sends the IP address to its parent
    • X sends control information < add X , G(X), > to server when joining the system
      • : expiration time when the first R-block of the video is no longer in the cache of X
  • Join Algorithm
    • Server S has the list of peers at the youngest generation for each video session, denoted as G y
    • Expiration time is the same for every member of the youngest generation
    • Initially, when the system is empty
      • is set to minus infinity
      • Set of youngest generation peers contains only S
  • Join Algorithm (cont.)
    • Case 1
      • If all of the existing video sessions are closed, X will be admitted if server S still has enough outbound-bandwidth
      • Otherwise, X will be rejected
    • Case 2
      • For the case where there is at least one existing video session still open, X will try to join that video session
  • Join Algorithm (cont.)
    • Case 2 proceeds as follows.
      • Step1
        • X contacts a random member of the G y set
        • acquires the list of peers at the super generation of G y .
      • Step2:
        • If t exp at the super generation > tj X , then go to Step3
        • Otherwise go to Step4
      • Step3: (generation not expired)
        • X selects a parent from the super generation
        • If such a candidate exists, X becomes a member of G y
          • X starts receiving the video stream from its selected parent
          • X sets its actual cache size ab X to conform to the caching rule
        • Otherwise go to Step4
  • Join Algorithm (cont.)
    • Case 2 proceeds as follows.
      • Step4: (generation expired)
        • A new generation is formed below G y
        • X becomes the first member of that generation
        • Actual cache size ab X is set to equal to MB
        • X selects a peer from G y as its parent
        • If no such peer exists, X tries other open video sessions or contacts the server
  • Parent Selection Criteria
    • Round Robin Selection
      • promote the fairness among peers
      • the requesting peer should select a peer, who hasn’t served any client for the longest period of time
    • Smallest Delay Selection
      • minimize the joining time of the requesting peer
      • the requesting peer picks the first peer in the candidate group, who has enough out-bound bandwidth
    • Smallest Distance Selection
      • reduce the number of links involved in the underlying network
      • the requesting peer chooses a peer, who has enough out-bound bandwidth and closest to it
  • Failure Recovery
    • P2VoD uses a two-phase failure recovery protocol
    • 1) Detecting failure
      • Grateful failures: When a peer leaves the system, it forwards the LEAVE_MESSAGE to its children
      • Unexpected failures: it happens unexpectedly without any explicit warning, peers in P2VoD are required to monitor their incoming traffic
  • Failure Recovery (cont.)
    • 2) Recovering from failures
      • Failure at a peer X , the whole sub-tree under X is affected
      • The rest of the sub-tree are informed to wait through the WAIT msg
      • A disrupted peer X finds a new parent
        • X contacts the siblings of its parent
        • If no such parent exists, X contacts the server
        • Otherwise, X is rejected
      • X succeeds, the sub-tree is recovered
      • X fails, the immediate children of X will invoke the recovery process
  • Performance Evaluation
    • Examine the effects of two parameters in P2VoD:
      • max number of clients allowed in the first generation of each video session, K
      • max buffer size each client can use, MB
    • Compare P2VoD with P2Cast
    • Network topology using GT-ITM
    • Clients arriving to system follow the Poisson distribution
    • one Transit network (with 4 nodes)
    • 12 stub domains (with 96 nodes)
    • backbone link support 25 streams
    • edge link support 7 concurrent streams
  • Performance Evaluation (cont.)
    • Rejection probability
      • probability that a client tries to join the system but can not get the service
    • Server stress
      • amount of bandwidth used at the server, or the number of streams established at the server
    • Number of contacts during the recovery
      • number of nodes a client has to contact during the recovery process
  • Rejection probability for various maximum buffer sizes (K = 3)
    • MB is varied from 0.1 to 0.4 of the length of the video
    • When doubling size of MB , the rejection probability is reduced by half
  • Server stress with various values of K (MB = 0.1)
    • In light workload, almost every clients get the video stream directly from the server
    • In heavy workload, most clients get the video stream from some other client, not the server
    • With small K, a failure at the first generation will likely cause disruption the whole video session
    • With large K, such failure only cause a portion of the
    • video session to be in
    • recovery mode
  • P2VoD vs. P2Cast: Client rejection probability
    • P2VoD use K =6 & MB = 0.2
    • The threshold for P2Cast is set at 0.2.
    • P2VoD outperforms BF because P2Cast requires each client to obtain two streams
  • P2VoD vs. P2Cast: Server stress
    • In P2VoD, a video session is open as long as clients in the G y still have the first block of the video buffer
    • In P2Cast, a video session is open for a short period of time starting when the first client join the video session and last for the length of the threshold
  • P2VoD vs. P2Cast: Failure overhead
    • Clients arrive to the system at a rate of 0.4 per second during a period of 2 hours (3516 clients)
    • When the failure probability increases, the number of clients contacted during a recovery decreases
      • more clients leave the system, network bandwidth is also released
      • easier for an affected client to find a new parent
  • Conclusion
    • P2VoD, a new system for Video-On-Demand streaming in a Peer-to-Peer environment
    • the concept of generation and caching scheme to deal effectively with failures
    • An efficient control protocol help P2VoD to allow clients join the system fast, as well as to recover failures in a quick and localized manner
    • Simulation-based performance study shows that P2VoD is superior than P2Cast