1. A simple model for analyzing P2P streaming protocols. Seminar on advanced Internet applications and systems Amit Farkash. 1

2. The problem: The engineering of streaming video from a server to a single client is well studied and understood. This, however, is not scalable to serve a large number of clients simultaneously. P2P streaming tries to achieve scalability (like P2P file distribution) while at the same time meet real time playback requirements. It is a challenging problem still not well understood. 2

3. The real world: While the problem may still not be well understood in practice P2P streaming seems to be working just fine. Even in Israel where upload speed is considerably low it is possible to receive a "watchable" stream. 3

4. The real world: Current popular P2P streaming softwares are: Usually streaming sporting events (illegally due to copyright violation). 4

5. P2P streaming vs. P2P file sharing: P2P streaming is less demanding – no need for entire file. 1) Peers join the video session from the point of their arrival times. 2) Missing “just a few” frames is tolerable. P2P streaming is more demanding - real time requirements! 5

6. Performance metrics: We will compare downloading strategies based on two performance metrics: Continuity – probability of continues playback. Startup latency – expected time to start playback. 6

7. Basic model: M – Number of peers in the network. A single server streaming chunks of video in playback order to M peers. Each chunk has a sequence number starting from 1. Time is slotted. Server selects a peer randomly in time t and sends it the chunk. 7

8. Basic model: Each peer maintains a buffer B that caches up to n chunks. B(n) is reserved for the chunk to be played back immediately while B(1) is used to store the newest chunk, that is distributed in the current time slot. At time t chunk t-n+1 is removed from the buffer and played back by the peer while all other chunks are shifted by 1. 8

9. Basic model: Goal: Ensure B(n) is filled as many time slots as possible. 9

10. Basic model: P k (i)[t] – probability that B(i) of peer k is filled (with the correct) chunk at time t. Assumption: this probability reaches a steady state for large t, namely P k (i)[t] = P k (i). We call P k (i) the buffer occupancy probability of peer k. 10

11. Basic model: Simple case - only server is distributing chunks: P k (1) = P(1) = 1/M. ∀ k. P k (i+1) = P(i+1) = P(i). i=1,…,n-1. ∀ k. Obviously very poor playback for any M>1. 11

12. Improvement: Each peer selects another peer in each time slot to try and download a chunk not already in its buffer. If the selected peer has no useful chunk, no chunk is downloaded in that time slot. Assume all peers use the same selection strategy, therefore have the same distribution P(i). Assume peers are selected randomly. 12

13. Improvement: Since peers are selected randomly the probability for a peer, A,to be selected by K≥0 peers is: A(k) = If M=100, A(3) is only about 1.8 % so let's assume A's peer's upload capacity is large enough to serve all requests in each time slot. 13

14. Chunk selection policy: First we define the following events: WANT(K,i) = B(i) of peer K is unfilled. HAVE(H,i) = B(i) of peer H is filled. SELECT(H,K,i) = Using a chunk selection strategy, peer K cannot find a more preferred chunk than that of B(i) that satisfied WANT and HAVE. 14

15. Chunk selection policy: For i=1,…,n-1 we get: P(i+1) = P(i)+Pr[WANT(K,i) ∩ Pr[HAVE(H,i)] ∩ Pr[SELECT(H,K,i)] ≈ P(i) + [1-P k (i)] P h (i) SELECT(i) = P(i) + [1-P (i)] P(i) SELECT(i) Note that P(i) is an increasing function, hence collaborating improves playback performance. 15

16. Chunk selection policy: We used the following assumptions to simplify our equation: Assume all peers are independent so P(i) is the same for each K, therefore: WANT(K,i) = 1-P(i). Assume large enough number of peers so that knowing the state of one does not significantly affect the probability of the state of another peer, therefore: Pr[HAVE(H,i)|WANT(K,i)] ≈ Pr[HAVE(H,i)]=P(i). Assume chunks are independently distributed in the network, so the probability distribution for position i is not strongly affected by the knowledge of the state of other positions, therefore: Pr[SELECT(H,K,i)|WANT(K,i) ∩ HAVE(H,i)] ≈ Pr[SELECT(H,K,i)] = SELECT(i). 16

17. Chunk selection strategies: Rarest first: Select a chunk, which has the fewest number of copies in the system. Well known strategy. Gives good scalability (Continuity). Greedy: Fill empty buffer locations closer to the playback time first. Low startup latency but fares poorly in continuity. 17

18. Greedy: Peer K will want to select the chunk closet to the playback deadline, which it doesn't already have. If B(n) is empty, it will select it. If B(n) is filled it will select B(n-1) and so on… This means peer K will select to download chunk to B(i) if B(j) are filled for every n>j>i and it was not distributed a chunk by the server. 18

19. Greedy: Pr[chunk isn't downloaded to B(j)] = ¬Pr[WANT(K,j)HAVE(H,j)] = Pr[K has j] + Pr[K doesn't have j] * Pr[H doesn't have j] = P k (j) + (1-P k (j)) (1-P h (j)) = P(j) + (1-P(j))² Therefore: SELECT G (i ) Proposition: SELECT G (i) = 1 - (P(n) - P(i+1)) - P(1) For Proof see paper, proposition 1.paper 19

20. Rarest first: For i=1,…,n-1: P(i+1) ≥ P(i), so the expected number of copies of chunk in B(i+1) is equal or greater than the expected number of copies of chunk in B(i). This means peer K will want to select to download chunk to B(1) unless B(1) is already filled, in this case K will select B(2) and so on… 20

21. Rarest first: Peer K will select to download chunk to B(i) if B(j) are filled for every 1≤j<i and it was not distributed a chunk by the server: Therefore: SELECT RF (i) Proposition: SELECT RF (i) = 1 – P(i) For Proof see paper, proposition 2paper 21

22. Results: We get the following difference equations: Rarest First: P(i+1) ≈ P(i) + P(i) [1-P (i)]² Greedy: P(i+1) ≈ P(i) + P(i) [1-P(i)] [1-P(1)-P(n)+P(i+1)] 22

23. Evaluating performances: We already have Continuity: P(n). Another performance metric is start up latency, the time a peer should wait before starting playback. Assuming all other peers have already reached steady states, we argue that a newly arriving peer should wait until its buffer has reached steady state as well. 23

24. Start up latency Assumption: when a peer K starts with an empty buffer every other peer H it contacts is likely to have a chunk for it to download. Therefore after time slots, K is expected to have acquired the same number of chunks as H, which is also, thus we have: Start up latency =. 24

25. Start up latency Is there a problem here with the Greedy strategy ? Assume start up latency for the Greedy strategy is 4 time slots and that on the second time slot, it successfully downloads a chunk to position B(n-1). Since we shift positions each time slot by 1, by the time the playback starts this chunk becomes obsolete. 25

26. Start up latency Suggested solution: Assume the start up latency for the Greedy strategy is S g, then Greedy has to download chunks to buffer positions less than n - S g in its first attempt. Positions less than n - (S g + 1) in its second attempt and so on… until playback starts. 26

27. Models from comparison: Discrete model – The solution for the buffer state distribution P(i) is derived numerically. For the Greedy Strategy we first give P(n) a fixed value, substitutes n steps inversely from P(n) to P(1) and compare P(1) with 1/M. If P(1) ≈ 1/M then we get the solution, else P(n) is adjusted accordingly and the inverse substitution process is repeated. 27

28. Models from comparison: Continuous model – Generally solved numerically using MatLab. Simulation model – Based on the discrete model. o One server and M peers. o In each time slot the server distributes one chunk to a random peer. o Each peer selects one random peer to download one chunk from and can upload up to two peers. 28

29. Rarest first vs. Greedy: M=1,000, n=40: 29

30. Mixed strategy: Trying to achieve Rarest first’s continuity (or even better) with lower start up latency. Always try to collaborate with others in order to improve performances, but if you can’t find a “rare” chunk to download and if positions closer to the playback are still unfilled, why not try to fill them up ? 30

31. Mixed strategy: Partition the buffer at point m. First, try to download a chunk using Rarest first to positions 1…m. If no chunk can be downloaded using Rarest first, use Greedy for positions m+1…n. 31

32. Mixed strategy: Difference equations: For B(1) to B(m) same as Rarest first: P(1) = 1/M. P(i+1) ≈ P(i) + P(i) [1-P(i)]² For B(m+1) to B(n) same as Greedy but substitute B(m) for B(1): P(i+1) ≈ P(i) + P(i) [1-P(i)] [ 1-P(m)-P(n)+P(i+1)] 32

33. Rarest first vs. Greedy vs. Mixed: We keep buffer size at n = 40 and we set m = 10. This means for the mixed strategy that buffer positions 1 to 10 are running Rarest first while buffer positions 11 to 40 are running Greedy. We’ll present results from the discrete model. 33

34. Rarest first vs. Greedy vs. Mixed: 34

35. Rarest first vs. Greedy vs. Mixed: 35

36. Optimizing the Mixed Strategy: Fix n to 40 and vary m: 36

37. Optimizing the Mixed Strategy: Adapting to peer population: One way is to observe the value of P(m). Set a target value, say P m = 0.3 When a peer finds the average of P(m) to be less than P m the peer increases m, else the peer decreases m. 37

38. Optimizing the Mixed Strategy: Simulation: Initial value of m is 10. Calculate average of P(m) for 20 time slots and then set new value of m. Initially M = 100 and every 100 time slots add another 100 peers (with empty buffers). 38

39. Optimizing the Mixed Strategy: 39

40. Summary: We first saw 2 different selection strategies: Rarest first: Good continuity but higher start up latency. Greedy: Low start up latency but poor continuity. We then introduced a mixed strategy. We showed it achieves better continuity than both of the above and lower start up latency than Rarest first. We show how to optimize the Mixed strategy. 40

41. Summary: Application to real world protocols: The Mixed strategy can be viewed as an optimization of the CoolStreaming protocol. The presented model does not try to capture all aspects of the implementation of CoolStreaming, however, the chunk selection strategy can be incorporated. The Mixed strategy is also compatible with BiTos and can be viewed as an alternative for it. 41

42. Think… In this version of mixed we choose to use Rarest first initially and use Greedy only if no chunk is found using the Rarest first strategy for positions 1 to m. What about the other way around ? Generally collaborate with others in order to improve performances, however, if for some reason, positions closer to the playback remain unfilled try to fill them up first. 42

43. Paper: A Simple Model for Analyzing P2P Streaming Protocols.  YiPeng Zhou, Dah Ming Chiu Information Engineering Department The Chinese University of Hong Kong  John C.S. Lui Department of Computer Science & Engineering The Chinese University of Hong Kong 43