Improving QoS in BitTorrent-like VoD Systems Yan Yang Alix L.H. Chow Leana Golubchik Dannielle Bragg Univ. of Southern California Harvard University InfoCom 2010 Presenter : 王裕博 Professor ：周承復 1

Outlines Abstraction Introduction Performance metrics and experimental setup Peer request problem Service scheduling problem Heterogeneous environment Conclusion 2

Abstraction Effective use of P2P-based system in providing large scale video streaming services. Focus on : –Load balance –FCFS is enough or not 3

Improving QoS in BitTorrent-like VoD Systems 4

Introduction P2p –Live streaming : performance, scalability, dynamics of p2p system PPLive, CoolStreaming –VoD (Voice over Demand) : high quality, full-length movie Joost, Hulu, Netflix, iTune Store 5

Introduction VoD v.s. Live streaming –Data diversity entire movie  only a playback buffer for several minutes The variance of playback deadlines of file pieces –large  small 6

Introduction BT –Most popular p2p system (35%) –Nearly optimal use of peer’s bandwidth –Node, tracker Adapting BT to VoD applications –Default piece selection strategy –TFT 7

Introduction Open question in p2p-based VoD –Peer request problem –Service scheduling problem 8

Introduction Peer request problem –“to which peer should a node send a request for a data piece” Random?(just a example) 9

Introduction Leading to losses in QoS –Two reasons 10

Introduction Service scheduling problem –“which request for data in its queue should a peer serve next” For QoS : do not miss as possible –“whether all requests for data pieces should be served” Two disadvantage 11

Performance metric and experimental setup Simulation : BT-simulator provide by [7] A little modification 12

Performance metric and experimental setup 13

Peer request problem Random –Send the request to a randomly default chosen neighbor Least Load Peer (LLP) –Send to neighbor with “the shortest queue size” 14

Peer request problem CI : 0.97 An unbalanced system  long incoming queue  increase the probability … sample 15

Peer request problem 50% of upload occurs after 80% of download is completed about 10% of upload(20% to 30% : about 3%) 16

Peer request problem Difficult to implement –Need to know the exact knowledge of instantaneous node queue lengths. –Trade off Message overhand : resulting system performance 17

Peer request problem Least Requested Peer (LRP) Tracker Assistant Yongest-N Peers (YNP) Closet-N Peers(CNP) 18

Peer request problem YNP, CNP improve a lot, for good choices of N. YNP can be quite sensitive to N. LRP does not perform well. LLP gives the best performance. 19

Peer request problem LLP with Stale Information (LLP-S) –Each node reports its queue length to its neighbor periodically. LLP Piggyback (LLP-P) –Piggyback LLP update messages on HAVE messages. –Explicit update messages, when no update message has been sent for T i time units. 20

Peer request problem Update interval is 30 seconds : 0.6 : 7.6 (msg. overhead) With piggybacking, CI is less sensitive (only drop 4% for 5s to 90s) 21

Service scheduling problem In what order should requests be reserved. Whether some request should be rejected. FCFS? 22

Service scheduling problem EDF(Early Deadline First) –Sort the queue by the request deadline. –Pick the request with the most urgent deadline to serve. 23

Service scheduling problem EDP(Early Drop) –Estimating the waiting time of a newly arrive request (insert or reject). –Re-evaluated after insertion. 24

Service scheduling problem Deadline-Aware Scheduling(DAS) –EDF + EDF All scheme shows significant improvement. YNP is less sensitive to N. LLP-P is less sensitive to the update interval threshold. (p.21) 25

Heterogeneous LLP-HLM –Queue length  (Queue length /upload bandwidth) YNP-HLM –Randomly choosing  weighted probability 26

Heterogeneous Improvement are not large. Significant improvement.  estimate? 27

Conclusion Posed and studied two fundamental problem, the peer request problem and the service scheduling problem. LLP-P DAS 28

Q&A 29

Thank you for your listening!! 30

(*)DAS overhand The better load balance is the scheme, the lower is the DoS overhead.(p.25) The total message overhead of LLP-P is still dominated by LLP update message. 31

(*)Is LLP-P Always Preferred With a larger peer set size, CI of both is improved. With a larger peer set size, message overhead of LLP-P increases. 32