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