A Measurement Study of a PeertoPeer Videoondemand System

1
A Measurement Study of a Peer-to-Peer
Video-on-demand System

• IPTPS 2007
• Bin Cheng, Xuezheng Liu, Zheng Zhang, Hai Jin

2
Outline

• GridCast system overview
• Key ideas
• VoD characteristics
• Routing table concentric rings (RINDY1)
• Content delivery mechanism
• Anchors Prefetching
• Measurement Analysis

3
GridCast system overview

• Web portal
• Media source
• Tracker
• Peers
• Ring based overlay

4
Key ideas

• VoD characteristics
• More selfish, a peer only cares about contents
  after its current playing position, which is
  often different from each other
• Mostly, downloading targets are those whose
  playback positions are ahead, and can only help
  those that are behind
• A peer can change its playing position at any time

5
Key ideas

• Hard to utilize globally optimal strategies such
  as rarest-first in BT
• To cope with the above problem
• Peer maintains a routing table
• Consisting of some peers that are placed in a set
  of concentric rings with power law radii
• Distanced using relative playback positions
• Update using Gossips

6
000

• This allows a peer to find a new group of
  position-close partners in log steps, after
  seeking to a new playing position

7
Content delivery mechanism

• Peers cache played content onto local disk
• for serving other peers
• or backward seeks itself
• Exchanges chunks (1 second) with its (up to 25)
  partners
• starting from those in the innermost ring and
  then outwards
• or from the source server otherwise.

8
Content delivery mechanism

• The peer fetches the next 10 seconds first
• the playback stalls if these data are not fetched
  in time.
• Next, it tries to fetch the next 200 seconds
• If bandwidth allows, the peer also tries to fetch
  anchors

9
Anchors Prefetching1

• When a seek occurs, adjust the playback position
  to the beginning of the closest anchor if the
  anchor has been already downloaded
• Thus, the seeking is satisfied instantly and the
  playing time of that anchor overlaps with the
  time needed for the peer to establish partners at
  the new position

10
Switch to C/S

• A peer will retrieve from the server if
• 1) the content exists only in the source server
• 2) the content does not exist in its local
  partners but exists in disconnected peers because
  of NAT and
• 3) its partners do not have sufficient bandwidth
  to meet the demand.

11
Measurement

• Deploy over CERNET
• More than 20,000 users
• 1 source server (100Mb bandwidth, 2GB memory, 1TB
  disk)
• Bitrate from 400Kbps to 600Kbps
• WMV, RMVB
• Two-month logs (30 second granularity)
• Seek operation, buffer maps, jitter, anchor usage
• Upload to tracker periodically
• with / without anchor prefetch for each month
  respectively

12
(No Transcript)
13
Overall System Performance

• Bandwidth consumption
• Channel utilization vs. popularity

14
(No Transcript)
15
User Experience

• Startup latency
• Seek latency
• Jitter
• (correlation with source server stress)

16
Startup latency has a wide distribution up to 60
seconds, more than 70 and 90 of sessions have
lower than 5 and 10 seconds, respectively. Seek
latency is smaller, more than 70 and 90 of the
sessions have lower than 3.5 and 8 seconds,
respectively. non-CERNET users poor latency
(close to 1 minute) because of lower network
capacity (45KB/s)
17
Server stress peaks when there are more users in
the system, but the amount of users is not the
reason for server stress increase More
concurrent users can drive up number of active
channels, leading to server stress growth and
degrading user experience for peers with fewer
partners.
18
Optimization

• Seeking behaviors
• Prefetching can be effective

19

• Forward seek dominates backward seek with a 73
  split
• Around 80 of seeks are within short distance
• This suggests that prefetching the next anchor
  relative to the current play position can be
  effective to improve random seeks

20
Cost-effective?
21

• The best strategy needs to consider the
  followings to reach the optimal tradeoff
• Prefetching the next anchor is statistically
  optimal from the individual users view
• On the other hand, rarest-first globally
  optimal in reducing the source servers load
• past sessions can provide guidance the parts
  that were played more are obvious candidates for
  prefetching

22
Related Papers

• 1 B. Cheng, H. Jin, and X.F. Liao, RINDY A
  Ring Based Overlay Network for Peer-to-Peer
  on-Demand Streaming, Proceedings of Ubiquitous
  Intelligence and Computing, Wuhan, 2006.
• 2 Liao Xiaofei, Jin Hai, OCTOPUS A Hybrid
  Scheduling Strategy for P2P VoD Services, GCC
  2007.

23
Q A

• Thanks.