Is Random Scheduling Sufficient in P2P Video Streaming?

download Is Random Scheduling Sufficient in P2P Video Streaming?

of 46

  • date post

    05-Jan-2016
  • Category

    Documents

  • view

    39
  • download

    0

Embed Size (px)

description

Is Random Scheduling Sufficient in P2P Video Streaming?. The 28th International Conference on Distributed Computing Systems. 課程: 同儕計算 日期: 2008.12.16. 報告者: 69721041 朱振伸 69721502 張欽天. 1. INTRODUCTION 2. RELATED WORK 3. P2P STREAMING: DESIGN AND IMPLEMENTATION - PowerPoint PPT Presentation

Transcript of Is Random Scheduling Sufficient in P2P Video Streaming?

  • Is Random Scheduling Sufficient in P2P VideoStreaming?The 28th International Conference on Distributed Computing Systems

    2008.12.1669721041 69721502

  • 1. INTRODUCTION2. RELATED WORK3. P2P STREAMING: DESIGN AND IMPLEMENTATION4. EVALUATION METHODOLOGY5. EXPERIMENTAL RESULTS6. CONCLUSIONS AND FUTURE WORK

  • INTRODUCTIONVideo-over-IP applications are quickly becoming the new generation killer applications on the InternetISPs (private IP networks) e.g. FiOS of Verizonclient-server basedP2P

  • INTRODUCTIONHow elaborate should a good P2P video streaming design be?focus on exploring design space to approach theoretical performance bounddeliver good user Quality to Experience with simple designs

  • Comparison studyModeling and analysisSimulationExperiments on InternetPlanetLab

  • PlanetLabAn overlay network testbedPlanetLab933 nodes454A software package

  • Three basic scheduling algorithmsRandom Pull scheduling (RP)Adaptive Queue Based Chunk scheduling (AQCS)Random Useful Packet Forwarding (RUPF)

    p.s. AQCS and RUPF have been theoretically proved to be optimum

  • Random Pull SchedulingA peer in RP scheduling randomly select M neighbors to serve.The value of M is chosen to be proportional to the peers upload capacity.A peer can request up to K data chunks from one serving peer.RP randomly selects missing chunks to pull

  • Random Pull Scheduling

  • Adaptive Queue-based Chunk SchedulingA fully connected mesh among participating peersData chunks are pulled/pushed from the server to all peers, cached at peers forwarding queues, and relayed from peers to their neighbors

  • Adaptive Queue-based Chunk Scheduling

  • Random Useful Packet Forwardingthe mesh is fully connectedthe most-deprived peerSource server gives highest priority to the fresh data chunks that have not been sent out before

  • Random Useful Packet ForwardingpushpullA large number of duplicate chunks are observedA high percentage of chunks miss their playback deadlinesOutdateCollisionuplink capacity sometimes cannot be fully utilized.

  • RUPF vs RPRUPF selects M most deprived peersRF select M random peersThe source server in RUPF pushes out fresh data chunk firstRandom Pull with Fresh chunk first (RPF)Random Pull with Most-Deprived peer selection (RPMD)

  • Random Useful Packet Forwarding

  • EVALUATION METHODOLOGYExperiment Setting10, 000 lines of C++ code100 PlanetLab nodesnodes are TCP connections20% peers have upload capacity of 128kbps40% have 384kbps25% have 1Mbps15% have 4Mbps

  • EVALUATION METHODOLOGY

    average upload bandwidth is around 1Mbpseach node collects related statistics every secondestimates the average upload and download rate per ten seconds.

  • EVALUATION METHODOLOGYPerformance Metricschunk miss ratiothe number of data chunks which miss the playback deadline over the total number of data chunks that peer should receive.peer bandwidth utilizationaverage upload rate/the peers pre-set upload capacityplayback delaywhen a chunk is generated at the source until it is played at the peer side

  • V. EXPERIMENTAL RESULTSFive different P2P streaming designs1. Random Pull (RP), 2. Random Pull with Fresh first policy (RPF),3. Random Pull with Most-Deprived peer selection (RPMD),4. Random Useful Packet Forwarding (RUPF) and Adaptive5. Queue-based Chunk Scheduling (AQCS).

  • P2Pnpeer

    server peer

  • The bandwidth resource index

    the ratio of the total uploading resources in the system to the total resource demand at streaming rate of r

  • In AQCS, the chunks size is set to be 1KByte, and the server replies each pull signal with only one chunk.The server increases the streaming rate by increasing the number of chunks generated per second.

  • In RUPF and RP, we fix the buffer map size at 120bits(15 bytes).The download window is set to be 30 seconds and moves forward every 10 seconds.The server produces four chunks per second and increases the streaming rate by increasing the chunk size (this way the buffer map size remains the same).

  • CDF= Cumulative Distribution Function value (the user data access cost over light load and heavy load)94%80%72%

  • B. Impact of Server Scheduling Rule and CapacityThe experiment results suggest that (i) the fresh-chunk-first scheduling at source server plays an important role in improving the system performance; (ii) most deprived scheduling, although has been theoretically shown to be optimal , does not seem to bring performance improvement in our experiments.

  • 960Kbps1100Kbps5-a

  • B. Impact of Server Scheduling Rule and Capacity()3.2Mbps< 960Kbps , 0960Kbps server

  • serverload5LoadingLoading

  • Server (6)

  • 7

  • 7

  • C. Impact of Buffering DelayIn client-server based video streaming, client side video buffering is necessary for continuous playback in face of network bandwidth variations.

    (640kbps,1Mbps)1. = 10 Chunk23%2. = 30 Chunk 5%

    =>

  • D. Impact of Peering Topology and Degree100 Planetlab nodespeed 640kbyte/s1. Degree(1). peerdegree = 6 = 20%(2). peerdegree =10 = 5%(3). peerdegree =14 = 3%

  • 2. the average hop count (1) peers 6 , chunk 6 hops(2) peer 14, 4.

  • Peer

    1. peer 14 degree2. 10%peer12%degree 133. 40%peer20%degree 94. peer

  • Large peering degree helps in improving system robustness in the face of peer churn.

    degree=1850%peer15%degree=10 50%peer30%

  • VI. CONCLUSIONS AND FUTURE WORK1. several key factors contributing most to the successes of simple P2P streaming designs on the current Internet.

    2. In the future work, we are interested in exploring different ways to extrapolate our results to draw more general conclusions on P2P systems with different sizes

  • 1. P2P400k

    2. PC

    3.

    P2P??P2PP2PP2P??P2PPlanetLabP2Ppeerpeer pull(RP) 2. (RPF) 3. (RPMD)4. (RUPF) 5. (AQCS)UsserverUiserverUspeerUr40PlaneLabserver1Mbps480kbps9602.21.1300300104480kbps (=2.2)P2P400KbpsP2P480kbps(RP)(RPMD)RPFRUPF960KbpsAQCSPeer960Kbps(( = 1.1)RPRUPF35% 11%AQCS04bpeerPeerAQCS94%RUPF80%RP72% RUPFRPpeer4 aRPRPFRPFRPServerRPFRPRUPFRPMDPEERRUPFRPMDRP1. 1Mbpsserver3.2MbpsserverAQCSRUPFRP5-a(RPMDRPFRPRUPF)960kbps0960KbpsRUPFRPAQCS1100

    RUPFRPserver7-a : 480kbps,RUPF7-A10PeerpeerpeerRUPFAQCS1120kbpsRUPF20.2 AQCS0server103.2peerpeerRP640kbps1Mbps10508-aRPP2PPeerPeerserver peerRUPF,3010AQCS15

    1418610

    P2P100