Slide 1

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

Slide 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

Slide 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

Slide 4

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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 9

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

Slide 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

Slide 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

Slide 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

Slide 13

Improvement: Since peers are selected randomly the probability for a peer, A,to be selected by K0 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 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

Slide 21

Rarest first: Peer K will select to download chunk to B(i) if B(j) are filled for every 1j