**5. Model-based analysis of PPLive at system level**

In the section we try to discuss the systematic problems and design concerns on performance, scalability and stability. Based on the live peer's startup models, we will analyze PPLive's design goals, and how PPLive tends to reach the goals; VoD network sharing environment will be analyzed and the inherent connection with user behavior will be revealed.

#### **5.1 System stability based on different initial offset placement schemes**

We next introduce two initial offset placement schemes either based on the first neighbor's offset lag or based on its buffer width. We will show how different system design goals can be reached under different schemes, and explain why good peer selection mechanism is critical to make the schemes stable.

#### **5.1.1 Initial offset placement based on offset lag**

The first model of initial offset placement makes a new peer (called host as before) decide its *initial offset* based on its *first neighbor*'s offset lag (Li & Chen, 2008a). Assume host *h* chooses a chunk ID as the *initial offset* and begins to fetch chunks at time *t*0. After a time interval *s*, the host starts to drain chunks out of buffer to playback. Then, the offset lag of the host is, *Lh=s(t)-fh(t) =s(t0)+r(t-t0) –r(t-t0-s)- =s(t0)+rs-.* 

As a system designer, for minimizing the workload of tracker server, a person hopes that the wanted chunks are fetched as much as possible from other peers instead of tracker. Thus, the initial offset should be chosen when at least one BM has been received for a peer *p* and should be appropriate larger than peer *p*'s offset *fp*(*t*0). On the other hand, too much diversity among offset lags is not good for sharing environment, so a system designer would wish to control the offset lag, i.e., *LhLp* = *fp*(*t*0)*+rs.*

It seems a good criterion to let the *LhLp*=0*.* We call such scheme as *fixed padding* (FP) because of *=fp*(*t*0)+*r<sup>s</sup>* where *rs* is a constant padding. However, FP has no design space.

Reverse Engineering the Peer to Peer Streaming Media System 111

There is a physical explanation for the turnover threshold *csch*(*t*) in PPLive. We have

*ftk(t)=t+W\*-120=t+90=t+β.* Intuitionally, chunks below *ftk*(*t*) may can only be buffered by peers, but those above *ftk*(*t*) are cached by both seeder and peers. Designers would like to see a system where peer caches as many as useful chunks while seeder doesn't, and make use of

On the other side, let *vq*(*t*)=*Vq*(*t*)+*t* be the playable video of a neighbor peer *q*. All chunks below *vq*(*t*) are already fetched by peer *q* at time *t*, but chunk *vq(t)+1* definitely is not. If we set *csch*(*t*)>*vq*(*t*) and assume *q* is the only neighbor for host *p*, then after peer *p* gets chunk *vq*(*t*), he has to idly wait for peer *q* to fetch chunk *vq(t)+1* according to the TB protocol. If we design *csch*(*t*)*<vq*(*t*), peer *p* will not waste its time. Substituting model parameters into it, we

same distribution with a mean *V*\* and stand deviation σ*V*, then we deduced another design

is introduced to guarantee the switch threshold is below the playable video of his neighbor with larger probability. Based on our measurement in PPLive, *V*\* is about 196 and σ*V* is about 18. For a threshold of 90, is 2. Through the discussion of system design considerations, we hope to support the claim that PPLive is a well-engineered system.

In P2P-based file sharing systems, the number of copies is an important indication to the

at this time. Our statistics shows that chunks with larger IDs have less availability.

*)=1*, while

Fig.15. In each subfigure there are 86 curves in light color, which correspond to

*,t)* at time t, then both the results of

*(*

*(*

*,t)* calculated at 1, 2, . . . ,86 minutes of our trace time. Clearly, all the light color curves in each subfigure are very similar. This indicates that the SP and SD are well defined in a

The user watching behavior will affect the network sharing environment, and an inherent connection does exist between user behavior and VoD network sharing, i.e. the SP and SD can be analytically deduced from the distribution of WI. The theorems 1 and 2 in (Li & Chen, 2010) further verify the time-invariant property of SP and SD. yIn Fig.15, the thick black curve is the result theorem 1 in (Li & Chen, 2010). Clearly, the thick curves match the measured light color curves quite well in all subfigures. Equation 3 in theorem 1 says that the average number of copies is related to the second moment of WI. It indicates that the diversity in users' behaviors can promote network sharing, and this provides twofold

availability of data blocks. We define the number of copies of chunk

Σ *N(*

normalized availabilities as the *sharing profile* (SP)

 *(* *<sup>s</sup>*. If any possible download rates are considered, the right side of

*,t)*, which equals the number of online peers having this chunk

*)*, can be observed independent of time *t*. We named these

*,t)* by the total number of online peers *N(t)*, or the total

σ*V*-

*<sup>s</sup>*. If further assuming *Vq*(*t*) for any peer *q* has the

*(,t)= N(,t)/ N(t)*≈

*)*, and *sharing distribution* (SD)

*)* is not. Both SP and SD are shown in

*s*, where coefficient

in the network at a

*()*. *()*

*(,t)* or

*()* 

*s* for *0≤t<*

*<sup>s</sup>*, which happens to be *the seeder offset ftk*(*t*) (reported by tracker) since

*<sup>s</sup>* from 70s to 35s, the peer needs a

*s+B* seconds. if one wants to decrease the

stable peers' resources to help startup peers. Thus *β* has a lower limit as *β*≥90.

faster *rmin* , which will impact the startup performance.

survivor after

*csch(t)=t+β for t≥*

have *β<Vq(t)+t-*

*s*, for *0≤t<*

the inequality has a minimal value *Vq*(*t*)-

**5.3 VoD network sharing environment** 

given time *t* as *availability N(*

number of copies *C(t)=*

practical P2P VoD system.

and *(,t)= N(,t)/C(t)*≈*(*

*(*

Moreover, if we normalize *N(*

is a probability distribution as ∑

rule (Li & Chen, 2010) for the upper limit of *β* as *β<V\*-*

One can easily find that all peers in such a system will have the same *offset lag LWtk*. Buffer width is an important design parameter involving playback performance. Larger buffer can improve playback continuity, but does no good to a tracker for consuming more memories. Thus, FP can't fulfill two design goals at same time: large buffer of peer but small buffer of tracker.

Let's consider a more practical scheme named as *proportional placement* (PP) *based on offset lag*, i.e., *=fp*(*t*0)+*Lp*, where is constant placement coefficient less than 1, and *Lp* is the first neighbor's offset lag. Since the first neighbor must have been a new peer when it entered the system, we can refer to a very familiar formula *xn*+1=*bxn*+*c*, which is a contraction mapping when the Lipschitz condition satisfies *b*<1. One can easily concludes that such a system has a stable point *L*\*=*rs*/, which is independent of any specific initial offset.

Self-stabilizing is the most attractive property of *proportional placement* scheme. However, in certain extreme conditions, it may lead to a poor performance. For example, the first neighbor has an offset lag of *Lp*=1000 but only contains 50 chunks in his buffer. With a placement coefficient *=*0.3, the host's *h=fp*(*t*0)+300, and the host doesn't have any available chunk for download.
