**3.2 The communication protocol cracking**

In general, the protocol crack is a cycling procedure including following steps:

**Network sniffer/measurement**: In the first step, performed using a client sniffer, we capture the interactive packets between the local peer and others. We get to know the important protocol messages must be there such as *shake hand* message, buffer map message (*BM*), and peer list message (*peerlist*), based on existing research reports and our experience. By connecting those types of message to the sniffer trace, it is not difficult to distinguish all kinds of message, even though some messages' functions are unknown.

**Protocol message guess**: Next, we observe each message in different dimensions, including the dimensions of time, channel and peer. For facilitating observation, we use a small software (developed by us) to extract the wanted messages with some query conditions, such as source IP/port, destination IP/port and message type, from the traces. From the extracted records, we can see many regular patterns which help parse the detailed format of each message. Of course, this way doesn't always work well, for the minority of messages can't be explained. So, we don't neglect any available reference information, e.g., we have ever found the fields of total upload/download count and upload/download speed per peer contained in BM based on the information displayed in PPStream client window. In general, we crack more than 80% messages for PPLive, PPStream and UUSee.

**Test and Confirmation:** In this stage, we analyze and validate the interactive sequences of messages. We guess and try different interactive sequences until the normal peer or tracker gives the right response. At last, nearly all the guesses are confirmed by our successfully and legally access to the real network.

Fig. 2. Buffer and buffer map

Reverse Engineering the Peer to Peer Streaming Media System 99

watchers and a few content servers are seeders. On the other hand, a P2P VoD system also contains two roles. However, they are not classified based on whether a peer has a complete file or not. Although most VoD peers do not own a complete video, he can share it once he is online regardless of the viewing channel. In a channel, we name a peer never downloading from others as a *contributor*, and a peer downloading from others as a *watcher*. VoD *watcher* is just like live watcher in many aspects, while VoD *contributor* may not necessarily have a complete file. As a *contributor*, the VoD peer may upload one movie while watching another. A significant difference of a VoD system from a live system is that *contributors* largely outnumber *watchers*. Our measurement shows that about two-

Nearly all existing studies simply assume a stable playback rate. Thus we start with the problem of video playback rate measurement to launch our analysis. Then, we raised the questions of how a peer reaches its stable playback state, and whether and how a peer can

Intuitively, the forward BM offset with time *t* in peer *p*, noted as *fp*(*t*), is connected to its playback rate. According to our experience, small rate changes are hidden if we were to

playback rate *r* can make the changes obviously. However, to check every peer's playback rate is a hard job. In practice, each peer has its own playback rate which roughly equals to the system playback rate, otherwise video continuity cannot be ensured. Thus, a system playback rate should be found as a common reference for observing peer offset progress.

We describe the system playback process by a *service curve s*(*t*)*.* It is reasonable to use the system maximal chunk ID at any time *t* as *s*(*t*), and then playback rate is *r*(*t*) =*ds*(*t*)/*dt.* For a channel with playback rate variations, the playback rate vs. time should be a piecewise

The procedure of finding the rate change is similar to the method in estimating the clock skew in network delay measurements. In (Zhang, 2002), people presented "Convex\_Hull\_L" algorithm and a segmented algorithm, which are denoted as CHU and SCHU respectively in our research, to calculate the network delay. However, referring to Fig.3, the convex envelope (dash line) calculated by CHU fails to reflect the rate changes in medium time scale in our trace 070502. Through slightly modifying SCHU algorithm, we get a new method called Piecewise Line Envelop Approximation (PLEA) (Li & Chen, 2009). The *rate reset time* {*tk*} and *reset rate* {*rk*} is simply the turn point and slope of each segment in the piecewise line calculated by PLEA respectively. The key of PLEA is to take convex hull only in small time scale and follow the rate variation in medium time scale. Thus, a parameter

segmentation is automatically adjusted during the calculation procedure without pre-

assigned or fixed. The square marked line in Fig.3 shows the result of PLEA with

is introduced. An observed point will be kept if the time difference

. Unlike SCHU, our

*=*1500s. It

*fp*(*t*) with proper value of

thirds peers are *contributors*.

**4.1.1 Playback rate and service curve** 

keep in good shape.

linear function.

named as *follow-up time*

between this point and previously saved point is larger than

**4.1 Live peer behavior in P2P streaming media system** 

visualize *fp*(*t*) directly as a time sequence. Instead, a curve of *rt*

Though the crack process, we get to know some principle of the system. In the P2P system, the video streaming is split into many blocks called *chunks*, each of which has a unique ID. In general, *chunk ID* is sequentially assigned in ascending order, i.e. the earlier played chunk has smaller ID as Fig.2 shown. A seeder injects chunks one by one into the network and each peer caches the received chunks in a buffer. Live peer only caches a small fraction of the whole video, while VoD peer caches almost the whole video. A peer buffer is usually partially filled. The downloaded chunks -- the shadow square in Fig.2 are shared, while the empty areas need to be filled by downloading from others. For enabling the key sharing principle between P2P users, a message *BM* is introduced to exchange the buffer information between peers. Referring to Fig.2, for a peer *p*, its BM contains two parts, an offset *fp* and a bitmap. The offset *fp* is the oldest chunk ID, i.e., the smallest chunk ID in a buffer. The bitmap is a {*0,1*} sequence, which length indicates the buffer width *Wp*. In the bitmap, a value of 1, respectively 0 at the *ith* position start from left to right means that the peer has, respectively has not the chunk with *IDoffset+i-1*. Since a peer constantly fetches new chunk to fill its buffer and shifts the expired chunk out of the buffer, the chunk IDs at both ends of the buffer will go forward with time, we name the BM *offset* time sequences of as *offset curve fp*(*t*) and the largest chunk ID time sequence in the peer's BM as *scope curve <sup>p</sup>*(*t*). Obviously, the difference between them is the peer's *buffer width Wp*(*t*)=*<sup>p</sup>*(*t*)-*fp*(*t*). Usually, *Wp*(*t)* fluctuates with time. In addition, we get a very useful finding in tracker *peerlist* message: Different from the *peerlist* of a peer, the tracker *peerlist* has two important extra fields, *TkOffMin* and *TkOffMax*, corresponding to the buffer head (called *seeder offset ftk*) and buffer tail (called *seeder scope tk*) of the seeder, respectively. Obviously, the seeder's buffer width is *Wtk=tk-ftk.* The finding can be proved in next section.

#### **3.3 Network measurement and dataset**

Using the cracked protocols, we succeeded for the first time to develop crawlers that measure different P2P streaming media systems in a large scale. The crawler first reads a channel's index file. Then it starts to collect BMs and peerlist messages returned by tracker or peers into a log file as the raw trace for our offline studies, meanwhile we insert a local timestamp into each message. The crawler runs on a PC server (512 kbps ADSL home line, window XP, 2.4 GHz CPU, and 1 GB memory). The VoD crawler trace used in this chart is captured from PPLive on October 26, 2007, and lasts for about 90 min. The live crawler trace is also captured from PPLive during the time period from Apr. 2 to Jul. 15, 2007. With the crawlers, nearly all peers in any given channel can be detected, so that much more properties can be found. However, crawler is incapable of detecting a peer within its very beginning stage because the startup peer doesn't emit any signaling messages to a normal peer/crawler. Thus, a live sniffer trace, which is captured on July 3, 11, 12 and 15, 2007 by using a sniffer tool, is used to analyze the startup progress. We call it an experiment for each client sniffing and the trace totally contains about 2500 experiments.

#### **4. Reverse engineering analysis from a peer's viewpoint**

Like the BT system, live peer may play roles of *leecher(watcher)* or *seeder*. A seeder has the complete video, while a leecher hasn't. In a P2P live streaming media system, all peers are 98 Reverse Engineering – Recent Advances and Applications

Though the crack process, we get to know some principle of the system. In the P2P system, the video streaming is split into many blocks called *chunks*, each of which has a unique ID. In general, *chunk ID* is sequentially assigned in ascending order, i.e. the earlier played chunk has smaller ID as Fig.2 shown. A seeder injects chunks one by one into the network and each peer caches the received chunks in a buffer. Live peer only caches a small fraction of the whole video, while VoD peer caches almost the whole video. A peer buffer is usually partially filled. The downloaded chunks -- the shadow square in Fig.2 are shared, while the empty areas need to be filled by downloading from others. For enabling the key sharing principle between P2P users, a message *BM* is introduced to exchange the buffer information between peers. Referring to Fig.2, for a peer *p*, its BM contains two parts, an offset *fp* and a bitmap. The offset *fp* is the oldest chunk ID, i.e., the smallest chunk ID in a buffer. The bitmap is a {*0,1*} sequence, which length indicates the buffer width *Wp*. In the bitmap, a value of 1, respectively 0 at the *ith* position start from left to right means that the peer has, respectively has not the chunk with *IDoffset+i-1*. Since a peer constantly fetches new chunk to fill its buffer and shifts the expired chunk out of the buffer, the chunk IDs at both ends of the buffer will go forward with time, we name the BM *offset* time sequences of as *offset curve fp*(*t*) and the largest chunk ID time sequence in the peer's BM as *scope curve*

Obviously, the difference between them is the peer's *buffer width Wp*(*t*)=

*tk-ftk.* The finding can be proved in next section.

**4. Reverse engineering analysis from a peer's viewpoint** 

buffer tail (called *seeder scope*

**3.3 Network measurement and dataset** 

width is *Wtk=*

experiments.

*Wp*(*t)* fluctuates with time. In addition, we get a very useful finding in tracker *peerlist* message: Different from the *peerlist* of a peer, the tracker *peerlist* has two important extra fields, *TkOffMin* and *TkOffMax*, corresponding to the buffer head (called *seeder offset ftk*) and

Using the cracked protocols, we succeeded for the first time to develop crawlers that measure different P2P streaming media systems in a large scale. The crawler first reads a channel's index file. Then it starts to collect BMs and peerlist messages returned by tracker or peers into a log file as the raw trace for our offline studies, meanwhile we insert a local timestamp into each message. The crawler runs on a PC server (512 kbps ADSL home line, window XP, 2.4 GHz CPU, and 1 GB memory). The VoD crawler trace used in this chart is captured from PPLive on October 26, 2007, and lasts for about 90 min. The live crawler trace is also captured from PPLive during the time period from Apr. 2 to Jul. 15, 2007. With the crawlers, nearly all peers in any given channel can be detected, so that much more properties can be found. However, crawler is incapable of detecting a peer within its very beginning stage because the startup peer doesn't emit any signaling messages to a normal peer/crawler. Thus, a live sniffer trace, which is captured on July 3, 11, 12 and 15, 2007 by using a sniffer tool, is used to analyze the startup progress. We call it an experiment for each client sniffing and the trace totally contains about 2500

Like the BT system, live peer may play roles of *leecher(watcher)* or *seeder*. A seeder has the complete video, while a leecher hasn't. In a P2P live streaming media system, all peers are

*<sup>p</sup>*(*t*).

*<sup>p</sup>*(*t*)-*fp*(*t*). Usually,

*tk*) of the seeder, respectively. Obviously, the seeder's buffer

watchers and a few content servers are seeders. On the other hand, a P2P VoD system also contains two roles. However, they are not classified based on whether a peer has a complete file or not. Although most VoD peers do not own a complete video, he can share it once he is online regardless of the viewing channel. In a channel, we name a peer never downloading from others as a *contributor*, and a peer downloading from others as a *watcher*. VoD *watcher* is just like live watcher in many aspects, while VoD *contributor* may not necessarily have a complete file. As a *contributor*, the VoD peer may upload one movie while watching another. A significant difference of a VoD system from a live system is that *contributors* largely outnumber *watchers*. Our measurement shows that about twothirds peers are *contributors*.

#### **4.1 Live peer behavior in P2P streaming media system**

Nearly all existing studies simply assume a stable playback rate. Thus we start with the problem of video playback rate measurement to launch our analysis. Then, we raised the questions of how a peer reaches its stable playback state, and whether and how a peer can keep in good shape.

#### **4.1.1 Playback rate and service curve**

Intuitively, the forward BM offset with time *t* in peer *p*, noted as *fp*(*t*), is connected to its playback rate. According to our experience, small rate changes are hidden if we were to visualize *fp*(*t*) directly as a time sequence. Instead, a curve of *rtfp*(*t*) with proper value of playback rate *r* can make the changes obviously. However, to check every peer's playback rate is a hard job. In practice, each peer has its own playback rate which roughly equals to the system playback rate, otherwise video continuity cannot be ensured. Thus, a system playback rate should be found as a common reference for observing peer offset progress.

We describe the system playback process by a *service curve s*(*t*)*.* It is reasonable to use the system maximal chunk ID at any time *t* as *s*(*t*), and then playback rate is *r*(*t*) =*ds*(*t*)/*dt.* For a channel with playback rate variations, the playback rate vs. time should be a piecewise linear function.

The procedure of finding the rate change is similar to the method in estimating the clock skew in network delay measurements. In (Zhang, 2002), people presented "Convex\_Hull\_L" algorithm and a segmented algorithm, which are denoted as CHU and SCHU respectively in our research, to calculate the network delay. However, referring to Fig.3, the convex envelope (dash line) calculated by CHU fails to reflect the rate changes in medium time scale in our trace 070502. Through slightly modifying SCHU algorithm, we get a new method called Piecewise Line Envelop Approximation (PLEA) (Li & Chen, 2009). The *rate reset time* {*tk*} and *reset rate* {*rk*} is simply the turn point and slope of each segment in the piecewise line calculated by PLEA respectively. The key of PLEA is to take convex hull only in small time scale and follow the rate variation in medium time scale. Thus, a parameter named as *follow-up time* is introduced. An observed point will be kept if the time difference between this point and previously saved point is larger than . Unlike SCHU, our segmentation is automatically adjusted during the calculation procedure without preassigned or fixed. The square marked line in Fig.3 shows the result of PLEA with *=*1500s. It

Reverse Engineering the Peer to Peer Streaming Media System 101

By sniffing many single clients, the typical events in peer startup progress are revealed in Fig.5. For simplicity, we call a startup peer as *host*. The first event is the *registration* message a host sends to the tracker after selecting a channel. We take the registration time as the *reference time* 0. After certain *tracker response time Ttk* the host gets a peerlist response from the tracker, which contains a list of online peer addresses and the seeder buffer information (*TkOffMin* and *TkOffMax*). Next, the host connects to the peers known from the peerlist. Shortly after, the host receives its *first BM* at *peer response time Tp,* and the sender of the first BM is correspondingly called the *first neighbor p*. After that, the host chooses an initial chunk as its start point and begins to fetch chunks after that chunk. We denote the time when a host sends its first chunk request as the *chunk request time Tchk*. After a while, the host starts periodically advertising its BM to the neighbors. The time when a host sends its first BM is named as the *host advertising time Tad*. This time breaks the whole start process into two phases: the *silent phase* and the *advertising phase*. Only in the advertising phase, a host can be sensed by an outside crawler. We find that, in a short time period after *Tad*, host reports an invariant BMs' offsets, which indicates a host is busy in building his buffer so that it's not the time to start to play video. At the time called *offset initial time Toff* when the host begins to move the BM offset forward, we think the host begins to drain data out from its buffer for

and can only be detected by client sniffer. While after *Tad*, time points of *Tad* and *Toff* can be collected by either our crawler or a sniffer. We use both two platforms to measure peer's

buffer message

advertises his Host issues first

*Tck Tp Tchk Toff* Time *t*

startup process and use *Tad* as the common reference to connect both platforms.

chunk request

Host issues first

*<sup>s</sup>*= *Toff*–*Tp*. Time points of *Ttk*, *Tp*, and *Tchk* are all in the silent phase

drain his buffer

Host starts to

*<sup>s</sup>* is defined as the time duration

**4.1.2 The observation of a peer based on key events** 

playback. By the way, an oftenly-used *offset setup time* 

tracker

response from

Host receives first

buffer message

Host receives first

*Tad*

0

Fig. 5. Events and their occurring time in PPLive

tracker Host registers to

between *Tp* and *Toff*, i.e.

Fig. 6. PDF of

*s '*

fits the envelope of trace quite well. Comparing PLEA to SCHU in Fig.3, the result of PLEA is much smoother.

Fig. 3. PLEA v.s. others algorithms

Fig. 4. Comparison of our algorithms

Besides PLEA, we have an occasional but very useful finding during reverse engineering. In PPLive, the seeder's buffer width *Wtr*(*t*) reported by tracker, which is the difference of seeder's scope minus its offset, is always equals to the product of 120 and current playback rate *r*, i.e., *Wtr*(*t*)=120*r*(*t*). For validation, we draw all the rate curves calculated from PLEA of tracker scope *tr*(*t*) and peers max scope *max(t), i.e., RPLEA*(*tr*(*t*)) and *RPLEA*(*max(t)*), as well as *Wtr*(*t*)/120 in the same trace in Fig.4. All rate curves match well except some individual points. Thus we have following observations: For any PPLive channel, the instantaneous rates deduced from both tracker scope and peer maximal scope equal each other, and they are about 1/120 of the seeder's *buffer width*, i.e., *RPLEA*(*tr*(*t*))=*RPLEA*(*max*(*t*))=*Wtr(t)/*120.

Then new questions are naturally raised. Whether has the system took the rate variations into account in design? When rate change occurs, can that lead a peer to restart? All such questions involve a primary problem, what is operating mechanism of a peer, especially in its early stage.

100 Reverse Engineering – Recent Advances and Applications

fits the envelope of trace quite well. Comparing PLEA to SCHU in Fig.3, the result of PLEA

Besides PLEA, we have an occasional but very useful finding during reverse engineering. In PPLive, the seeder's buffer width *Wtr*(*t*) reported by tracker, which is the difference of seeder's scope minus its offset, is always equals to the product of 120 and current playback rate *r*, i.e., *Wtr*(*t*)=120*r*(*t*). For validation, we draw all the rate curves calculated from PLEA of

*Wtr*(*t*)/120 in the same trace in Fig.4. All rate curves match well except some individual points. Thus we have following observations: For any PPLive channel, the instantaneous rates deduced from both tracker scope and peer maximal scope equal each other, and they

Then new questions are naturally raised. Whether has the system took the rate variations into account in design? When rate change occurs, can that lead a peer to restart? All such questions involve a primary problem, what is operating mechanism of a peer, especially in

*max(t), i.e., RPLEA*(

*tr*(*t*))=*RPLEA*(

*tr*(*t*)) and *RPLEA*(

*max*(*t*))=*Wtr(t)/*120.

*max(t)*), as well as

is much smoother.

Fig. 3. PLEA v.s. others algorithms

Fig. 4. Comparison of our algorithms

*tr*(*t*) and peers max scope

are about 1/120 of the seeder's *buffer width*, i.e., *RPLEA*(

tracker scope

its early stage.

#### **4.1.2 The observation of a peer based on key events**

By sniffing many single clients, the typical events in peer startup progress are revealed in Fig.5. For simplicity, we call a startup peer as *host*. The first event is the *registration* message a host sends to the tracker after selecting a channel. We take the registration time as the *reference time* 0. After certain *tracker response time Ttk* the host gets a peerlist response from the tracker, which contains a list of online peer addresses and the seeder buffer information (*TkOffMin* and *TkOffMax*). Next, the host connects to the peers known from the peerlist. Shortly after, the host receives its *first BM* at *peer response time Tp,* and the sender of the first BM is correspondingly called the *first neighbor p*. After that, the host chooses an initial chunk as its start point and begins to fetch chunks after that chunk. We denote the time when a host sends its first chunk request as the *chunk request time Tchk*. After a while, the host starts periodically advertising its BM to the neighbors. The time when a host sends its first BM is named as the *host advertising time Tad*. This time breaks the whole start process into two phases: the *silent phase* and the *advertising phase*. Only in the advertising phase, a host can be sensed by an outside crawler. We find that, in a short time period after *Tad*, host reports an invariant BMs' offsets, which indicates a host is busy in building his buffer so that it's not the time to start to play video. At the time called *offset initial time Toff* when the host begins to move the BM offset forward, we think the host begins to drain data out from its buffer for playback. By the way, an oftenly-used *offset setup time <sup>s</sup>* is defined as the time duration between *Tp* and *Toff*, i.e. *<sup>s</sup>*= *Toff*–*Tp*. Time points of *Ttk*, *Tp*, and *Tchk* are all in the silent phase and can only be detected by client sniffer. While after *Tad*, time points of *Tad* and *Toff* can be collected by either our crawler or a sniffer. We use both two platforms to measure peer's startup process and use *Tad* as the common reference to connect both platforms.

Fig. 5. Events and their occurring time in PPLive

Fig. 6. PDF of *s '*

Reverse Engineering the Peer to Peer Streaming Media System 103

For simplicity, we assume the *initial offset* decision is based on the host's *first neighbor p*. Then, host *h* faces two alternatives -- based on either the tracker or its first neighbor. Seeing Fig.7, at time *th*, host *h* gets values of *s*(*th*)=*TkOffMax* and *ftk*(*th*)= *TkOffMin* from tracker, and

*lag*, host's *buffer width* maybe not large enough for a good playback performance. So what

We extract the marked points shown in Fig.7 at time *th* from our 2502 experiments, and draw them as a function of sorted experiment sequence in ascending order of *Wtk* and *Wp(t)* in Fig.8 where we take *ftk*(*th*) as the horizontal zero reference. The red lines are the seeder's buffer width *Wtk=*(*s*(*th*)*ftk*(*th*)). The top one is *Wtk* and the bottom one is *Wtk*. Clearly, PPLive mainly serves two playback rates: 10 chunks/s on the right area and 6 chunks/s on

vertical distance between top red '-' and *green 'x'* is peer p's offset lag *Lp=sfp*. Thus, Fig.8 confirms that PPLive takes certain variable buffer width scheme. Furthermore, seeder has a

We think certain kind of *Proportional Placement* (PP) strategy (Li & Chen, 2008a) can be introduced to make the decision of *initial offset*. Referring to Fig.8, the distance of the initial offset to its first received BM's offset is somehow proportional to the first

> *h=fp*+*WWp* or

*<sup>p</sup>f p* or the first neighbor's offset lag *Lp=sf p*. Thus, we guess

*LLp*, where the

*W=*(*h* *W* and *L* 

*fp*)/*Wp* and

*h=fp*+

*h* will shift out of the neighbor *p*'s buffer at time *th*+(

between which marks in each experiment is peer p's buffer width *Wp=*

PPLive doesn't adopt a fixed initial offset lag scheme, or else all *blue '*

*h* have more time to fetch this chunk. However, as too large

are the design principles behind the initial offset selection?

the left area. The *black '.'* and *green 'x'* stand for

larger buffer than normal peer. The *blue '*

adapt to *first neighbor p's* buffer condition.

*p*(*th*), *vp*(*th*) and *fp*(*th*) from its first neighbor *p*. Then the host should choice its

*'* is hosts relative initial offset lag

*'* and *green 'x'* have a similar shape, which means that *initial offset* may

*<sup>p</sup>*(*th*), beyond which scope no chunk is available. For further explanation,

*hfp*(*th*))/*r*. Large

*<sup>p</sup>ftk* and *fpftk* respectively, the distance

*<sup>h</sup>* will lead to a very small *offset* 

*<sup>p</sup>fp*. Similarly, the

*<sup>h</sup>ftk*. Obviously,

*'* would keep flat.

*h*

*<sup>h</sup>* lets host

values of

the chunk

between *fp*(*th*) and

Actually the *blue '*

Fig. 7. The startup model

neighbor's buffer width *Wp=*

PPLive chooses the *initial offset* either by

are the scale coefficients*.* Based our measurement, both PDFs of

Firstly, we measure the events in the silent phase. Statistic based on our 2502 client sniffing experiments shows that the *Tad* is a multiple of 5s and in most of cases *Tad* 5s. Most trackers return their responses within 0.02 seconds. *Tp* has an evenly distribution in the time interval [0.9s 2s]. Among *Ttk*, *Tp*, *Tchk* and *Tad*, no time points are tightly dependent. The average values of *Ttk*, *Tp* and *Tchk* are 0.058s, 1.419s and 2.566s respectively.

Secondly, we measure the events in advertising phase. The sniffer method is not used because it can only detect limited hosts which are under our control. With our crawler, nearly all the peers in any given channel can be detected, so that much more properties can be found. For each peer *p,* we get the offset *fp*(*t*) at each discrete time of {*tp*,*<sup>i</sup>*}. Not every peer caught by our crawler is a host since many peers have already been there before the crawler inquiries them. A principle is used to extract the hosts from our trace, i.e., a host should have an invariable offset in its early BMs and then increase the offsets later. Two problems are involved in inferring the exact value of *Toff* from BM records. First, *Tad* is often missed out in BM records. In the most cases, a host has been in progress for uncertain time before our crawler queries him. Second, we can't get the exact time when a host starts to drain data from his buffer because the time span between *Tad* and *Toff* may last for several tens of seconds. We take following measures. *Buffer fill Uh(t),* which is the number of all downloaded chunks in the buffer, i.e., the number of 1s in a BM at time *t* for a given host *h*, is used to solve the first problem. We only choose the peer meeting the condition *Uh(t)* ≤ certain threshold as a host, and take the timestamp of its first BM as its *advertising time Tad*. For checking if the threshold introduces biases, we try different thresholds. For the second problem, we take two different methods to estimate that time when a host changes its offset. Let *t*1 and *t*2 be the timestamps of the earliest two BMs with different offsets *f*(*t*1)*f*(*t*2) . One is the simple arithmetic average (AA) *Toff* =(*t*1+*t*2)/2, and the other is the linear interpolation (LI) *Toff*=*t*2(*f*(*t*2)*f*(*t*1))/*r*. The relative offset set time *s '* for a host is calculated as *s '* =*ToffTad*. The probability distribution functions (PDFs) of *s '* estimated by AA and LI with different thresholds are plotted in Fig.6. The similarity of the results can validate above methods. Therefore, we get peer's *offset setup time s*=*s ' +*(*Tad Tp*)70s where the mean value of *s '* is about 66s and *TadTp* is about 51.4193.6s measured in silent phase. Then, what is the root reason for that constant, why not other values? Let's dig it more deeply.

#### **4.1.3 Model-based observation of peer initial offset selection**

We name the peer's first wanted chunk as the *initial offset . W*e reconstruct a peer startup model in Fig.7 to explain the importance of initial offset. Assuming a constant playback rate *r*, *service curve s(t)* is a global reference. Assuming a constant seeder buffer width *Wtk*, we have the seeder's offset curve *ftk*(*t*)=*s*(*t*)-*Wtk* below *s(t)*. The host's first neighbor *p*'s *offset curve* and *scope curve* (of its largest chunk ID) are *fp(t)* and *p(t)* respectively. Since the number of successive chunks in a buffer indicates how long the video can be played continually, we follow (Hei et al., 2007b) to name that as the *buffer's playable video Vp(t)*, correspondingly the *peer's playable video vp(t)=f*p*(t)+ Vp(t)*, which is also drawn in Fig.7. The initial offset is very important for that, once it, saying *<sup>h</sup>*, is chosen at certain time *th*, the host's offset lag *Lh*=*s*(*t*)-*fh*(*t*) is totally determined. As shown in Fig.7, *fh*(*t*) begins to increase after the *s*, meanwhile *s*(*t*) has increased *rs*. Since the host initial offset lag is *L*=*s*(*th*)*<sup>h</sup>*, its *offset lag* at last is *Lh*=*L+r<sup>s</sup>*. *Lh* is the playback lag, but also the possible maximum buffer width. It means *<sup>h</sup>* can affect the system sharing environment.

102 Reverse Engineering – Recent Advances and Applications

Firstly, we measure the events in the silent phase. Statistic based on our 2502 client sniffing experiments shows that the *Tad* is a multiple of 5s and in most of cases *Tad* 5s. Most trackers return their responses within 0.02 seconds. *Tp* has an evenly distribution in the time interval [0.9s 2s]. Among *Ttk*, *Tp*, *Tchk* and *Tad*, no time points are tightly dependent. The average

Secondly, we measure the events in advertising phase. The sniffer method is not used because it can only detect limited hosts which are under our control. With our crawler, nearly all the peers in any given channel can be detected, so that much more properties can be found. For each peer *p,* we get the offset *fp*(*t*) at each discrete time of {*tp*,*<sup>i</sup>*}. Not every peer caught by our crawler is a host since many peers have already been there before the crawler inquiries them. A principle is used to extract the hosts from our trace, i.e., a host should have an invariable offset in its early BMs and then increase the offsets later. Two problems are involved in inferring the exact value of *Toff* from BM records. First, *Tad* is often missed out in BM records. In the most cases, a host has been in progress for uncertain time before our crawler queries him. Second, we can't get the exact time when a host starts to drain data from his buffer because the time span between *Tad* and *Toff* may last for several tens of seconds. We take following measures. *Buffer fill Uh(t),* which is the number of all downloaded chunks in the buffer, i.e., the number of 1s in a BM at time *t* for a given host *h*, is used to solve the first problem. We only choose the peer meeting the condition *Uh(t)* ≤ certain threshold as a host, and take the timestamp of its first BM as its *advertising time Tad*. For checking if the threshold introduces biases, we try different thresholds. For the second problem, we take two different methods to estimate that time when a host changes its offset. Let *t*1 and *t*2 be the timestamps of the earliest two BMs with different offsets *f*(*t*1)*f*(*t*2) . One is the simple arithmetic average (AA) *Toff* =(*t*1+*t*2)/2, and the other is the linear interpolation

> *s '*

*s '*

thresholds are plotted in Fig.6. The similarity of the results can validate above methods.

model in Fig.7 to explain the importance of initial offset. Assuming a constant playback rate *r*, *service curve s(t)* is a global reference. Assuming a constant seeder buffer width *Wtk*, we have the seeder's offset curve *ftk*(*t*)=*s*(*t*)-*Wtk* below *s(t)*. The host's first neighbor *p*'s *offset* 

number of successive chunks in a buffer indicates how long the video can be played continually, we follow (Hei et al., 2007b) to name that as the *buffer's playable video Vp(t)*, correspondingly the *peer's playable video vp(t)=f*p*(t)+ Vp(t)*, which is also drawn in Fig.7. The

host's offset lag *Lh*=*s*(*t*)-*fh*(*t*) is totally determined. As shown in Fig.7, *fh*(*t*) begins to increase

*<sup>h</sup>* can affect the system sharing environment.

*s*=*s ' +*(*Tad*  for a host is calculated as

1.4193.6s measured in silent phase. Then, what is the root

*s*. Since the host initial offset lag is *L*

*<sup>s</sup>*. *Lh* is the playback lag, but also the possible maximum buffer

estimated by AA and LI with different

*. W*e reconstruct a peer startup

*p(t)* respectively. Since the

=*s*(*th*)*<sup>h</sup>*, its

*<sup>h</sup>*, is chosen at certain time *th*, the

*Tp*)70s where the mean value of

*s '* =*ToffTad*.

> *s '* is

values of *Ttk*, *Tp* and *Tchk* are 0.058s, 1.419s and 2.566s respectively.

(LI) *Toff*=*t*2(*f*(*t*2)*f*(*t*1))/*r*. The relative offset set time

The probability distribution functions (PDFs) of

*Tp* is about 5

**4.1.3 Model-based observation of peer initial offset selection** 

*curve* and *scope curve* (of its largest chunk ID) are *fp(t)* and

initial offset is very important for that, once it, saying

*s*, meanwhile *s*(*t*) has increased *r*

*+r*

We name the peer's first wanted chunk as the *initial offset* 

reason for that constant, why not other values? Let's dig it more deeply.

Therefore, we get peer's *offset setup time*

about 66s and *Tad*

after the

width. It means

*offset lag* at last is *Lh*=*L*

For simplicity, we assume the *initial offset* decision is based on the host's *first neighbor p*. Then, host *h* faces two alternatives -- based on either the tracker or its first neighbor. Seeing Fig.7, at time *th*, host *h* gets values of *s*(*th*)=*TkOffMax* and *ftk*(*th*)= *TkOffMin* from tracker, and values of *p*(*th*), *vp*(*th*) and *fp*(*th*) from its first neighbor *p*. Then the host should choice its *h* between *fp*(*th*) and *<sup>p</sup>*(*th*), beyond which scope no chunk is available. For further explanation, the chunk *h* will shift out of the neighbor *p*'s buffer at time *th*+(*hfp*(*th*))/*r*. Large *<sup>h</sup>* lets host *h* have more time to fetch this chunk. However, as too large *<sup>h</sup>* will lead to a very small *offset lag*, host's *buffer width* maybe not large enough for a good playback performance. So what are the design principles behind the initial offset selection?

We extract the marked points shown in Fig.7 at time *th* from our 2502 experiments, and draw them as a function of sorted experiment sequence in ascending order of *Wtk* and *Wp(t)* in Fig.8 where we take *ftk*(*th*) as the horizontal zero reference. The red lines are the seeder's buffer width *Wtk=*(*s*(*th*)*ftk*(*th*)). The top one is *Wtk* and the bottom one is *Wtk*. Clearly, PPLive mainly serves two playback rates: 10 chunks/s on the right area and 6 chunks/s on the left area. The *black '.'* and *green 'x'* stand for *<sup>p</sup>ftk* and *fpftk* respectively, the distance between which marks in each experiment is peer p's buffer width *Wp=<sup>p</sup>fp*. Similarly, the vertical distance between top red '-' and *green 'x'* is peer p's offset lag *Lp=sfp*. Thus, Fig.8 confirms that PPLive takes certain variable buffer width scheme. Furthermore, seeder has a larger buffer than normal peer. The *blue ''* is hosts relative initial offset lag *<sup>h</sup>ftk*. Obviously, PPLive doesn't adopt a fixed initial offset lag scheme, or else all *blue ''* would keep flat. Actually the *blue ''* and *green 'x'* have a similar shape, which means that *initial offset* may adapt to *first neighbor p's* buffer condition.

Fig. 7. The startup model

We think certain kind of *Proportional Placement* (PP) strategy (Li & Chen, 2008a) can be introduced to make the decision of *initial offset*. Referring to Fig.8, the distance of the initial offset to its first received BM's offset is somehow proportional to the first neighbor's buffer width *Wp=<sup>p</sup>f p* or the first neighbor's offset lag *Lp=sf p*. Thus, we guess PPLive chooses the *initial offset* either by *h=fp*+*WWp* or *h=fp*+*LLp*, where the *W* and *L*  are the scale coefficients*.* Based our measurement, both PDFs of *W=*(*hfp*)/*Wp* and

Reverse Engineering the Peer to Peer Streaming Media System 105

respectively. A peer fetches chunks sequentially in strategy I, while in strategy II it may always fetch the latest chunk first. At the switch point to strategy II, the chunk ID's sudden

We believe the downloading strategies switch may be base on certain ratio threshold of buffer filling, and a closer observation can support this guess. As shown Fig.9, BM offset *fp*(*t*) keeps flat in the early 65s. Then, the peer starts to shift the offset forward. Let's see the flat playable video *Vp*(*t*) curve duration time [40s, 80s]. We can infer the first flat part in period of [40s, 65s] is for that the peer is downloading the latest chunks according to strategy II. If with the same strategy, the curve of the rest part in period of [65s,80s] should have had sloped downwards. Thus it must have changed the fetch strategy again from strategy II to I, which let peer fetches the most urgent chunks first so as to keep the *Vp*(*t*) at certain

At last, all curves of *Wp*(*t*), *Vp*(*t*) and *Up*(*t*) converge after a time around 80s, which is named

chunk within the buffer are fetched. It proves that the latest chunk is fetched firstly by

The whole progress can be approximated by a set of piecewise linear functions by a threshold bipolar (TB) protocol, which is very simple in its implementation and design philosophy. For a host, when the current *Vp* ≤ a threshold, the urgent task is to download the most wanted chunks, while if *Vp* > the threshold, the job is switched to help spread the latest or rarest chunks over the network. We have ever observed some other peers' startup

By further observation, the piecewise line model involves six structure parameters including video *playback rate r*, peer *initial download rate rp*, fetching strategy *switch* 

the *offset lag W*\*. Among them, *r* and *rp* cannot be designed and the rest four can. Assuming a constant *r* and a constant *rp*, based on the superposition principle at the key

*<sup>p</sup>* relative to the first neighbor's offset and

procedures in our trace, and all of them can be interpreted easily by the TB protocol.

*<sup>s</sup>*, the *initial offset*

*sch*, *cvg*].

*cvg*. A sudden big jump in *Vp*(*t*) at this time indicates that the last wanted

*sch*, we call the downloading strategies used by a peer as strategy I and strategy II

and after

threshold.

as *convergence time* 

strategy II in most of the period of [

*threshold Csch*, *offset setup time*

increase leads to an enlarged buffer width.

Fig. 9. A PPLive peer's evolution

*L=*(*hfp*)/*Lp* have the very high peaks at the same coefficient 0.34. The scaled errors of 100(*<sup>W</sup>*0.34) is shown with the cyan color in Fig.8. It seems that PPLive more likely uses a scheme based on the first neighbor's buffer width since *<sup>W</sup>* has a more sharp distribution. To check whether the selected *initial offset* is easy to download, as well as to evaluate whether PPLive has been designed to make host set its *initial offset* at the most suitable point locally or globally, we have studied the chunk availability. As a result, a host usually receives BMs from 4.69 peers before fetching any chunks. In more than 70% experiments, host can fetch chunks around from at least 3 neighbors. It indicates a good initial downloading performance.

Fig. 8. The measured initial parameters

#### **4.1.4 Model-based peer observation in the startup stage**

Once the initial offset is chosen, the host begins to download chunks. We use a simple model to help understand the data fetching process. For any given peer *p*, the model contains two parts. One is *buffer filling process,* expressed by curves of *buffer width Wp(t), playable video in buffer Vp(t), and buffer fill Up(t)* which is the number of all downloaded chunks in the buffer at time *t.* They reflect a buffer's local conditions, but can't tell the status of peer process in a global sense. The other is *peer evolutionary process* depicted by curves of *offset fp(t),* scope *<sup>p</sup>*(*t*), peer *playable video vp(t), download up(t)=fp(t)+Up(t)* and the reference *s(t).*  Ideally, for a CBR video, all evolutionary process curves should have the same slope equals to the playback rate *r*. One real progresses of the model can refer to Fig.9. The top line is *s(t)* as the reference line, the black line at the bottom shows the offset curve *fp*(*t*), and the cyan curve close to *s(t)* is *up*(*t*); the solid red curve with mark 'x' is *Wp*(*t*), the green curve with mark '\*' is *Up*(*t*), and the blue curve with mark '+' is the *Vp*(*t*).

Obviously, the downloading procedure contains two kinds of strategies. In Fig.9, both *Wp*(*t*) and *Vp*(*t*) have a same switch point at (*sch*≈40s, *Csch*≈900). We guess, before time *sch*, a peer sequentially fetches chunks from small to large ID, which can be confirmed by the fact of the closeness of *Wp(t), Vp(t)* and *Up*(*t*) before *sch*. Ideally, the three curves should be the same. However, in real networks, some wanted chunks may not exist in its neighbors or a chunk request maybe rejected by its neighbor. At the switch time point *sch*, the big jump of *Wp*(*t*) indicates a fetch strategy change. Therefore, we name *sch* as the *scheduling switch time*. Before and after *sch*, we call the downloading strategies used by a peer as strategy I and strategy II respectively. A peer fetches chunks sequentially in strategy I, while in strategy II it may always fetch the latest chunk first. At the switch point to strategy II, the chunk ID's sudden increase leads to an enlarged buffer width.

Fig. 9. A PPLive peer's evolution

104 Reverse Engineering – Recent Advances and Applications

Once the initial offset is chosen, the host begins to download chunks. We use a simple model to help understand the data fetching process. For any given peer *p*, the model contains two parts. One is *buffer filling process,* expressed by curves of *buffer width Wp(t), playable video in buffer Vp(t), and buffer fill Up(t)* which is the number of all downloaded chunks in the buffer at time *t.* They reflect a buffer's local conditions, but can't tell the status of peer process in a global sense. The other is *peer evolutionary process* depicted by curves of

Ideally, for a CBR video, all evolutionary process curves should have the same slope equals to the playback rate *r*. One real progresses of the model can refer to Fig.9. The top line is *s(t)* as the reference line, the black line at the bottom shows the offset curve *fp*(*t*), and the cyan curve close to *s(t)* is *up*(*t*); the solid red curve with mark 'x' is *Wp*(*t*), the green curve with

Obviously, the downloading procedure contains two kinds of strategies. In Fig.9, both *Wp*(*t*)

sequentially fetches chunks from small to large ID, which can be confirmed by the fact of the

However, in real networks, some wanted chunks may not exist in its neighbors or a chunk

*<sup>p</sup>*(*t*), peer *playable video vp(t), download up(t)=fp(t)+Up(t)* and the reference *s(t).* 

*sch*≈40s, *Csch*≈900). We guess, before time

*sch*. Ideally, the three curves should be the same.

*sch*, the big jump of *Wp*(*t*)

*sch* as the *scheduling switch time*. Before

*sch*, a peer

whether PPLive has been designed to make host set its *initial offset* at the most suitable point locally or globally, we have studied the chunk availability. As a result, a host usually receives BMs from 4.69 peers before fetching any chunks. In more than 70%

scheme based on the first neighbor's buffer width since

To check whether the selected *initial offset*

experiments, host can fetch chunks around

initial downloading performance.

Fig. 8. The measured initial parameters

and *Vp*(*t*) have a same switch point at (

closeness of *Wp(t), Vp(t)* and *Up*(*t*) before

*offset fp(t),* scope

**4.1.4 Model-based peer observation in the startup stage** 

mark '\*' is *Up*(*t*), and the blue curve with mark '+' is the *Vp*(*t*).

request maybe rejected by its neighbor. At the switch time point

indicates a fetch strategy change. Therefore, we name

*fp*)/*Lp* have the very high peaks at the same coefficient 0.34. The scaled errors of

*<sup>W</sup>* has a more sharp distribution.

is easy to download, as well as to evaluate

from at least 3 neighbors. It indicates a good

*<sup>W</sup>*0.34) is shown with the cyan color in Fig.8. It seems that PPLive more likely uses a

*L=*(*h*

100(

> We believe the downloading strategies switch may be base on certain ratio threshold of buffer filling, and a closer observation can support this guess. As shown Fig.9, BM offset *fp*(*t*) keeps flat in the early 65s. Then, the peer starts to shift the offset forward. Let's see the flat playable video *Vp*(*t*) curve duration time [40s, 80s]. We can infer the first flat part in period of [40s, 65s] is for that the peer is downloading the latest chunks according to strategy II. If with the same strategy, the curve of the rest part in period of [65s,80s] should have had sloped downwards. Thus it must have changed the fetch strategy again from strategy II to I, which let peer fetches the most urgent chunks first so as to keep the *Vp*(*t*) at certain threshold.

> At last, all curves of *Wp*(*t*), *Vp*(*t*) and *Up*(*t*) converge after a time around 80s, which is named as *convergence time cvg*. A sudden big jump in *Vp*(*t*) at this time indicates that the last wanted chunk within the buffer are fetched. It proves that the latest chunk is fetched firstly by strategy II in most of the period of [*sch*, *cvg*].

> The whole progress can be approximated by a set of piecewise linear functions by a threshold bipolar (TB) protocol, which is very simple in its implementation and design philosophy. For a host, when the current *Vp* ≤ a threshold, the urgent task is to download the most wanted chunks, while if *Vp* > the threshold, the job is switched to help spread the latest or rarest chunks over the network. We have ever observed some other peers' startup procedures in our trace, and all of them can be interpreted easily by the TB protocol.

> By further observation, the piecewise line model involves six structure parameters including video *playback rate r*, peer *initial download rate rp*, fetching strategy *switch threshold Csch*, *offset setup time <sup>s</sup>*, the *initial offset <sup>p</sup>* relative to the first neighbor's offset and the *offset lag W*\*. Among them, *r* and *rp* cannot be designed and the rest four can. Assuming a constant *r* and a constant *rp*, based on the superposition principle at the key

Reverse Engineering the Peer to Peer Streaming Media System 107

In summary, we have described how to approximate peer evolutionary progress based on the six parameters and the so-called design parameters in PPLive. In general, PPLive client has a good startup performance. In next section, we will reveal the systematic concerns

In general, A VoD peer can be classified as *contributor* or *watcher* based on whether the number of ones never increases in bitmap of the peer's BM or not during our observation. In our trace, most peers belong to either contributor or watcher. Less than 6% peers even advertised the abnormal all-zero BMs, the bitmap contained nothing. We guess such disordered behavior ascribed to software bugs, e.g. a user deletes his cache file suddenly. We name such those peers as Zpeer. Fig.12 draws the fractions of different peer groups in our measured channel 1. In fact, the rest two measured channel have the similar results. Those curves confirm that contributors always significantly outnumber watchers, and a

Further, two types of watching modes have been identified. People either watch a movie smoothly until his exit, or see a movie by jumping from one scene to another. We named the former as smooth watching mode and such viewer as smoother, and the latter as the jumping watching mode and that viewer as jumper. Obviously, smoother has continuous 1s in its BM, while jumper has discrete 1s. Table 1 lists the statistics on our trace. We find the majority are smoothers, while the jumpers cannot be ignored. It is different from that "most

Fig. 11. Probability distribution function of buffer progress (normalized)

**4.2 VoD user behavior in P2P streaming media systems** 

users always perform some random seeking" (Zheng et al., 2005).

stationary process can approximate the fractions.

Fig. 12. role ratios in channel 1.

behind the parameters design in PPLive.

points among the piecewise lines, it is not difficult to calculate other key time points, including *scheduling turnover time sch* and *convergence time cvg*, and then we can draw the piecewise lines. (Li & Chen, 2008b).

We are next interested to better understand the parameters design in PPLive. In order to generalize our discussion we consider all the relative parameters, including *Csch, p, W\**, and nearly all buffer progress parameters, to be normalized by playback rate *r*, and for simplicity, we use the same names for most of the normalized parameters as their originals.

We have known the *offset setup time <sup>s</sup>*70s in subsection 4.1.2. For *Csch*, we use *switch threshold factor β=Csch*/*r* instead of *Csch*. The calculation of *Csch* is a litter fussy, referring to Fig.9: *i)*. let *Csch*=*Wp*(*t*) just before the first jump of *Wp*(*t*); *ii).* Let *Csch*=*Vp*(*t*) just after the first big change in *dVp*(*t*)/*dt*; *iii)*. let *Csch* =mean of *Vp*(*t*) on its flat part; *iv).* let *Csch*=*Vp*(*t*) just before the jump of *Vp*(*t*). The results of all above methods are plotted in Fig.10, and we have *β=90s*. Next, *W\** is deduced from our crawler trace. Based on the statistics over total 15,831 peers lasting for at least 5 minutes since they entered stable state, we get a similar result for both normalized buffer width and offset lag relative to *s(t)*. At last, the *relative initial offset* is figured out from sniffer trace. The distribution of *W\** and *<sup>p</sup>* are shown in Fig.11. Based on our measurement, we have *W\*=*210s and *<sup>p</sup>* = 70s.

Corresponding to the different sort orders of *s*, *sch* and *cvg*, i.e. *s*<*sch*<*cvg*, *sch*<*s*<*cvg* and *sch*<*cvg*<*<sup>s</sup>*, after computation with these design parameters of PPLive, we get three groups of the buffer process, *Г*0={*p*: <*p≤*1.286}, *Г*1={ *p*: 1.286< *p≤*3} and *Г*2={*p*: *p*>3}, where *p* is the *normalized download rate p=rp/r.* Peers in group *Г*0 face a very poor startup condition. They take very long time to converge and the convergence time spans from 490s (about 8min) to infinite (*p*=1, never converge). According to our measured *<sup>p</sup>*, less than 10%peers belong to this group, while more than 70% peers belong to group *Г*1. Hence *Г*1 is the normal startup situation, and the convergence time is between 490s and 70s. Peers (more than 20%) in *Г*2 are so fast that they have converged before playing the video.

Fig. 10. Probability distribution function of β

106 Reverse Engineering – Recent Advances and Applications

points among the piecewise lines, it is not difficult to calculate other key time points,

We are next interested to better understand the parameters design in PPLive. In order to

and nearly all buffer progress parameters, to be normalized by playback rate *r*, and for simplicity, we use the same names for most of the normalized parameters as their

*threshold factor β=Csch*/*r* instead of *Csch*. The calculation of *Csch* is a litter fussy, referring to Fig.9: *i)*. let *Csch*=*Wp*(*t*) just before the first jump of *Wp*(*t*); *ii).* Let *Csch*=*Vp*(*t*) just after the first big change in *dVp*(*t*)/*dt*; *iii)*. let *Csch* =mean of *Vp*(*t*) on its flat part; *iv).* let *Csch*=*Vp*(*t*) just before the jump of *Vp*(*t*). The results of all above methods are plotted in Fig.10, and we have *β=90s*. Next, *W\** is deduced from our crawler trace. Based on the statistics over total 15,831 peers lasting for at least 5 minutes since they entered stable state, we get a similar result for both normalized buffer width and offset lag relative to *s(t)*. At last, the *relative initial offset* is

generalize our discussion we consider all the relative parameters, including *Csch,* 

*<sup>p</sup>* = 70s.

> *s*, *sch* and *cvg*, i.e. *s*<*sch*<*cvg*, *sch*<*s*<*cvg* and

of the buffer process, *Г*0={*p*: <*p≤*1.286}, *Г*1={ *p*: 1.286< *p≤*3} and *Г*2={*p*: *p*>3}, where *p* is the

take very long time to converge and the convergence time spans from 490s (about 8min) to

this group, while more than 70% peers belong to group *Г*1. Hence *Г*1 is the normal startup situation, and the convergence time is between 490s and 70s. Peers (more than 20%) in *Г*2 are

*<sup>s</sup>*, after computation with these design parameters of PPLive, we get three groups

*sch* and *convergence time*

*p=rp/r.* Peers in group *Г*0 face a very poor startup condition. They

*<sup>s</sup>*70s in subsection 4.1.2. For *Csch*, we use *switch* 

*cvg*, and then we can draw the

*<sup>p</sup>* are shown in Fig.11. Based on

*<sup>p</sup>*, less than 10%peers belong to

*p, W\**,

including *scheduling turnover time*

originals.

*sch*<*cvg*<

piecewise lines. (Li & Chen, 2008b).

We have known the *offset setup time*

our measurement, we have *W\*=*210s and

*normalized download rate*

Corresponding to the different sort orders of

Fig. 10. Probability distribution function of β

figured out from sniffer trace. The distribution of *W\** and

infinite (*p*=1, never converge). According to our measured

so fast that they have converged before playing the video.

Fig. 11. Probability distribution function of buffer progress (normalized)

In summary, we have described how to approximate peer evolutionary progress based on the six parameters and the so-called design parameters in PPLive. In general, PPLive client has a good startup performance. In next section, we will reveal the systematic concerns behind the parameters design in PPLive.

#### **4.2 VoD user behavior in P2P streaming media systems**

In general, A VoD peer can be classified as *contributor* or *watcher* based on whether the number of ones never increases in bitmap of the peer's BM or not during our observation. In our trace, most peers belong to either contributor or watcher. Less than 6% peers even advertised the abnormal all-zero BMs, the bitmap contained nothing. We guess such disordered behavior ascribed to software bugs, e.g. a user deletes his cache file suddenly. We name such those peers as Zpeer. Fig.12 draws the fractions of different peer groups in our measured channel 1. In fact, the rest two measured channel have the similar results. Those curves confirm that contributors always significantly outnumber watchers, and a stationary process can approximate the fractions.

Further, two types of watching modes have been identified. People either watch a movie smoothly until his exit, or see a movie by jumping from one scene to another. We named the former as smooth watching mode and such viewer as smoother, and the latter as the jumping watching mode and that viewer as jumper. Obviously, smoother has continuous 1s in its BM, while jumper has discrete 1s. Table 1 lists the statistics on our trace. We find the majority are smoothers, while the jumpers cannot be ignored. It is different from that "most users always perform some random seeking" (Zheng et al., 2005).

Fig. 12. role ratios in channel 1.

Reverse Engineering the Peer to Peer Streaming Media System 109

WI help us in better understanding user behavior. Fig.14 shows the CDF of WI for smoothers and jumpers in contributors. The x-axis of each subfigure is the chunk ID or bit positions in the BM. The y-axis is the fraction of the peers. The top curve and bottom curve are of smoother and jumper respectively. The middle curve is the fraction of jumper who has value 1s in its BM at a given bit position. As a peer frequently advertise its BM to others, those subfigures can also be interpreted as the sharing map among VoD peers. Based on this interpretation, we can draw the following conclusions: *i).* although most users are smoother, it may not be good for file-sharing. As lots of people only watch a few chunks, it may lead to overprovision around the initial chunks while under provision for the rest chunks; *ii).* Jumper promotes file-sharing. In each subfigure, the middle curve is significantly below the top curve line. It indicates a jumper contributes more chunks than a smoother. Furthermore, the bottom curve indicates jumpers contribute those chunks with large IDs which smoothers are incapable of sharing; *iii).* Even if jumpers contribute fewer chunks as a whole, their existence is still valuable, as the unbalanced provision resulted from smoothers can be

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

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

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

the host starts to drain chunks out of buffer to playback. Then, the offset lag of the host is,

 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

It seems a good criterion to let the *LhLp*=0*.* We call such scheme as *fixed padding* (FP)

as the *initial offset* and begins to fetch chunks at time *t*0. After a time interval

should be chosen when at least one BM has been received for a peer *p* and

*s.*

*s* is a constant padding. However, FP has no design space.

*s*,

will be analyzed and the inherent connection with user behavior will be revealed.

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

**4.2.2 User behavior understanding in terms of watching index** 

compensated to certain degree by jumpers.

critical to make the schemes stable.

chunk ID

the initial offset

because of

*=fp*(*t*0)+*r*

*Lh=s(t)-fh(t) =s(t0)+r(t-t0) –r(t-t0-*

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

*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,

would wish to control the offset lag, i.e., *LhLp* = *fp*(*t*0)*+r*

*<sup>s</sup>* where *r*

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


Table 1. Number of smoothers and jumpers

#### **4.2.1 Measureable parameter watching index in user behavior**

For quantitative analysis, we introduce *watching index (WI)* to name the position of the last "1" in a BM, which explains how many chunks a smoother has ever watched. Different from definition in (Yu et al., 2006), we use WI to emphasize the aspects of both time and space. As most peers are smoothers, a movie with a larger WI or longer tail in WI distribution in smoothers is usually considered to be more attractive. It means that people watched this movie longer or more people watch the movie. We use probability *pWI()* to represent the PDF of WI, which is the fraction of peers whose last "1" in their BMs are at the position . Fig.13(a) shows Cumulative Distribution Function (CDF) *FWI()=∑k≤ pWI(k)*. Obviously, channel 3 and channel 2 were the most and the least attractive respectively. Besides, online time is defined as how long a peer stays in a channel, and Fig.13(b) shows its CDF. Obviously, distributions of WI over all channels are significantly different but their online times are very similar. It indicates that WI is strongly related to the video content, while the contributor's online time is nearly independent of what he is currently contributing.

Fig. 13. CDF of WI and online time of contributors

Fig. 14. BM occupancies of contributors

108 Reverse Engineering – Recent Advances and Applications

For quantitative analysis, we introduce *watching index (WI)* to name the position of the last "1" in a BM, which explains how many chunks a smoother has ever watched. Different from definition in (Yu et al., 2006), we use WI to emphasize the aspects of both time and space. As most peers are smoothers, a movie with a larger WI or longer tail in WI distribution in smoothers is usually considered to be more attractive. It means that people watched this movie longer or more people watch the movie. We use probability *pWI(*

represent the PDF of WI, which is the fraction of peers whose last "1" in their BMs are at

. Fig.13(a) shows Cumulative Distribution Function (CDF) *FWI(*

Obviously, channel 3 and channel 2 were the most and the least attractive respectively. Besides, online time is defined as how long a peer stays in a channel, and Fig.13(b) shows its CDF. Obviously, distributions of WI over all channels are significantly different but their online times are very similar. It indicates that WI is strongly related to the video content, while the contributor's online time is nearly independent of what he is currently

*)* to

*)=∑k≤pWI(k)*.

Table 1. Number of smoothers and jumpers

Fig. 13. CDF of WI and online time of contributors

Fig. 14. BM occupancies of contributors

the position

contributing.

**4.2.1 Measureable parameter watching index in user behavior** 

#### **4.2.2 User behavior understanding in terms of watching index**

WI help us in better understanding user behavior. Fig.14 shows the CDF of WI for smoothers and jumpers in contributors. The x-axis of each subfigure is the chunk ID or bit positions in the BM. The y-axis is the fraction of the peers. The top curve and bottom curve are of smoother and jumper respectively. The middle curve is the fraction of jumper who has value 1s in its BM at a given bit position. As a peer frequently advertise its BM to others, those subfigures can also be interpreted as the sharing map among VoD peers. Based on this interpretation, we can draw the following conclusions: *i).* although most users are smoother, it may not be good for file-sharing. As lots of people only watch a few chunks, it may lead to overprovision around the initial chunks while under provision for the rest chunks; *ii).* Jumper promotes file-sharing. In each subfigure, the middle curve is significantly below the top curve line. It indicates a jumper contributes more chunks than a smoother. Furthermore, the bottom curve indicates jumpers contribute those chunks with large IDs which smoothers are incapable of sharing; *iii).* Even if jumpers contribute fewer chunks as a whole, their existence is still valuable, as the unbalanced provision resulted from smoothers can be compensated to certain degree by jumpers.
