Transcript of A simple model for analyzing P2P streaming protocols. Seminar on advanced Internet applications and...
- 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