# A simple model for analyzing P2P streaming protocols

date post

23-Feb-2016Category

## Documents

view

48download

0

Embed Size (px)

description

### Transcript of A simple model for analyzing P2P streaming protocols

A simple model for analyzing P2P streaming protocols.

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

1The problem:Streaming video from a server to a single client is well studied and understood.

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.

22IntroductionP2P Streaming System -P2P resolves this scalability problem by using all resources of all clients. It is like using multiple trees simultaneously to deliver content.

ServerPeerPeerPeerPeerPeerPeerFully connectedPeers maintain: * buffer * neighbor list 3P2P 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!

4Is this a real trade off ? Are people really likely to join the video session late (or leave early ?). Also, what will happen if file isnt delivered in its entirely in P2P file sharing ? 4Basic modelHow buffer works?

Server sends out chunks sequentially.Peer downloads one chunk every time slotBuffer shits ahead one position one time slotplaybackserver1t=12 1t=23 2 1t=3Buffer.5Model & Chunk Selection StrategiesM peers with the same playback requirementEach has a playback bufferIn each time slot, the server randomly selects one peer and uploads one chunkUsers metric is the continuity, defined as p(n) , the probability chunk n available To compute p(n), recursively compute p(i). p(i) is defined as: p(i)=prob(position i filled)

1 2 n1 2 n1 2 n M peersplaybackserver1/M1/M1/M6Basic modelPk(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 Pk(i)[t] = Pk(i).We call Pk(i) the buffer occupancy probability of peer k.

Simple case - only server is distributing chunks:

Pk(1) = P(1) = 1/M. k.

Pk(i+1) = P(i+1) = P(i). i=1,,n-1. k.

Obviously very poor playback for any M>1.

77Improvement: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 slotAll peers use the same selection strategy, therefore have the same distribution P(i)Assume peers are selected randomly.

8The paper does not discuss peer selection strategies. Of course we know from real life that peer selection strategies can improve performances.8Improvement:Since peers are selected randomly the probability for apeer, A ,to be selected by K0 peers is:

A(k) =

If M=100, A(3) is only about 1.8 % assume A's peer's upload capacity is large enough to serve all requests in each time slot.

9

9P2p technology effectModel & Chunk Selection StrategiesEach peers buffer is a sliding windowIn each time slot, each peer downloads a chunk from server or its neighborq(i) = the probability Buf[i] gets filled at this time slot, for i>11 2 np(1)=1/M p(n)=?time=t1 2 n t+1p(1)=1/Msliding window

P(1) = 1/M (Boundary)10Chunk selection policy:P(i+1) = P(i) + Q(i) = P(i) + Pr[WANT(K,i)Pr[HAVE(H,i)]Pr[SELECT(H,K,i)]

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).

11The last assumption is less accurate for some selection strategies than others.11Model & Chunk Selection Strategiesw(i) = probability peer wants to fill Buf[i] w(i)=1-p(i)h(i) = probability the selected peer has the content for Buf[i] h(i)=p(i)s(i) = Buf[i] determined by chunk selection strategyP(i) + [1-P(i)] P(i) SELECT(i)

1 2 i np(1)=1/M p(n)peer1 2 ... i n neighborp(1)=1/Msliding window

12Buffer mapX X X X 1 2 3 4 5 6 7 8playbackModel & Chunk Selection StrategiesGreedy Strategy -try to fill the empty buffer closest to playbackRarest First Strategy -try to fill the empty buffer for the newest chunk since p(i) is an increasing function, this means Rarest FirstAn example

RF SelectionGreedy Selection13Introduce chunk selection strategies: Greedy Strategy and Rarest First Strategy.

Performance metrics:We will compare downloading strategies based on two performance metrics:

Continuity probability of continues playback.

Startup latency expected time to start playback.14Which seems more crucial to you ?14Greedy: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] = Pk(j) + (1-Pk(j)) (1-Ph(j)) = P(j) + (1-P(j))

Therefore: SELECTG(i)

Proposition: SELECTG(i) = 1 - (P(n) - P(i+1)) - P(1)

For Proof see paper, proposition 1.15

15Rarest firstPeer K will select to download chunk to B(i) if B(j) arefilled for every 1j

*View more*