Upload
peregrine-patrick
View
218
Download
0
Embed Size (px)
DESCRIPTION
Abstraction Effective use of P2P-based system in providing large scale video streaming services. Focus on : –Load balance –FCFS is enough or not 3
Citation preview
Improving QoS in BitTorrent-like VoD Systems
Yan Yang Alix L.H. Chow Leana Golubchik Dannielle Bragg Univ. of Southern California Harvard University
InfoCom 2010Presenter : 王裕博
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.68 : 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 Ti 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