Main Scheme

Before explaining our proposal, we have several assumptions to introduce. First of all, we use push-pull model as our foundation, that is, peers in system form mesh-shape overlay structure and partners each share video chunk by round-robin discipline

simultaneously. As Figure 3.1 illustrates, there are lots of tracker servers who hold the streaming data source and peer-list, such as which peer watches which channel and every partner keeps its channel, available remaining UB (Upload bandwidth), which receiver to send to and which chunk to deliver. These assumption are commonly used both in traditional random and our proposed approach.

Figure 3.1 Round robin way on push-pull model.

We have extra assumption for our proposed approach, that is, every partner keeps its successor used to replace departed partners, the sequence number of successor can be calculated with three parameters including the sequence number of the departed peer and the number of partners in the following formula:

The sequence number of the successor partner = [(the sequence number of the

departed partner) + 1] modulus (the number of partners).

Every peer has a difference gap between upload bandwidth and download bandwidth, that is, all of peers in asymmetric network environment. Usually, the download bandwidth is bigger than the upload bandwidth of a peer.

Each peer is supposed to reserve certain upload bandwidth (UB) with factorβfor a partner departure, the value of factorβwill depend on the traffic of whole system, it can be dynamically adjusted by programmer. Every peer remembers its sequence number of parent and corresponding IP address. The sequence number of the video chunks can be calculated as follows:

Table 3.1 The explanation of the terminology

When a new peer joins the push-pull model P2P IPTV system, first of all, the new peer login and register to the tracker server to select a channel to watch. Tracker servers will give it a peer-list which watches the same channel and probably in the proximity of the peer. The upload bandwidth of these peers in the peer-list will close to the download bandwidth of the new peer.

The new peer chooses several peers as candidate partners from this peer-list, and makes connection to these candidate partners. The new peer tells these candidate partners to push the video chunks in a round-robin way.

The departure of partners is very often in most P2P IPTV systems, same in he

push-pull model, however, the traditional random approach cost long recovery switching time, this will significantly effect the QoE (Quality of Experience) of the system.

When a partner departed from the P2P IPTV system, we can categorize this situation into normal mode and abnormal mode. Normal mode means such partner departed from system on common situation that is to quit application manually or switch to another channel. On the other hand, abnormal mode means a partner departed from system on un-expected situation that is to shut down the computer suddenly or the power fails. The following parts have four figures corresponding to four situations for random approach, our proposed approach, normal mode and abnormal mode. Figure 3.2 explains how system recovers when one or more partners departed from the system in traditional random approach under normal mode.

Figure3.2 Partner departure for traditional random approach under normal mode

As shown in Figure 3.2, when partner 0 would like to depart from the P2P IPTV system, if it is under normal mode, that means it will notify the tracker server to arbitrarily choose a peer to replace this partner as its successor, hence, partner 0 issues a request message to the tracker server with some information such as the sequence number of partner 0, the Internet Protocol address of the partner 0, which channel peer 0 is watching, which chunks are partner 0 supposed sending to, receiver, the number of times, and the number of partners.

Tracker server arbitrarily selects a peer from peer-list to check if it has enough available upload bandwidth, watch the same channel and at least has the next chunk corresponding to partner 0 and adds it to the candidate partner list. Depending on information of peer 0 and the standard operating procedure, the tracker server will establish a sorted queue according to asymmetric network environment (the upload bandwidth of transmitter partners must close to the download bandwidth of the receiver partners)and distance (measured by the IP address of partners) between this successor partner and the new peer (the closer the better), then tracker server will choose the top entry of the queue as successor of partner 0 (named peer s), then move the pointer to the second entry of the queue, and issues a seek message to candidate successors with certain information (i.e. Partner 0 sequence number, next video chunk, receiver (the new peer), partner number, the number of times and so on) and setup a timer, if the timer expired, we think this candidate’s successor was gone or has not enough upload bandwidth, then tracker server will re-choose another candidate successor partner from the top of the sorted queue and move the pointer to next entry. If this candidate successor partner (successor 2) exists and has enough upload bandwidth, it will send the next chunk (calculated from the peer d sequence number, partner number and round) to

pass to the new peer as partner 0 normally did, and issues a update message to the new peer in order to refresh the IP address of the partner 0 sequence number which keeps in database of the new peer, then successor 2 issues a seek acknowledgment back to tracker server for reply, when tracker server receive this Ack message, it will issue a termination message to partner 0 to remove it from the system.

Several reasons cause the long recovery switching time in the traditional random approach, the first is to request and seek messages transmission in the long distance between partners in LAN and tracker servers on the Internet (far away from LAN), the second is to establish a sorted queue and doing standard operating procedure, the third is to repeatedly find suitable successors (exist and have enough upload bandwidth) as normal partners.

We proposed a method that dramatically reduces recovery switching time by choosing a local partner as a temporary successor partner until we get the steady successor partner via tracker servers.

Figure 3.3 Partner departure for proposed approach on normal mode

As Figure3.3 depicted, when partner 0 leave the system on normal mode in our proposed approach, it will issue a request message to partner 1 (the pre-defined successor of the partner 0), then partner 0 issues another request message to tracker servers to find out a steady successor partner. Since we have already reserved each peer’s upload bandwidth (the amount of upload bandwidth depend on β factor which is adjusted by programmer and depends on the traffic of the whole system as previously described), the partner 1 definitely has enough upload bandwidth to pass the sequentially video chunks to the new peer by issuing a data message and updates the new peer in order to refresh the IP address of the partner 0 sequence number to be partner 1 which is kept in the database of the new peer.

When the tracker server receives the request message sent from departed partner 0,

it will perform the standard operating procedure and establish a sorted queue with information within the request message (ex. the sequence number of partner 0, the IP address of the partner 0, channel, receiver, next chunk, the number of partners, the number of times and so on), the tracker server issues a notification message (with same information) to the successor (chosen from the top of the sorted queue and move the point to the second entry), the successor definitely has the enough upload bandwidth to pass the sequentially video chunks to the new peer, it issues a cancel message to the partner 1 to get the next chunk sequence number in order to send the sequential video chunks to the new peer. Finally, the successor will issue a re-update message to refresh the IP address of the partner 0 sequence number to be successor which is kept in the database of the new peer.

We can realize that less message and video chunks transmission distance between local partners comparing to long distance between partners in LAN and tracker servers in Internet. Since we have already defined the successor in the beginning, we do not need to find out a suitable successor by complex standard operating procedure or establish a sorted queue, furthermore we reserve certain upload bandwidth adjusted by programming according to the network traffic environment, therefore we can find the successor immediately and definitely.

As we mentioned earlier, partner departure can be spilt into normal mode and abnormal mode. In abnormal mode, partners leave from system in expected way, so we have to do something previously to solve this issue.

Figure3.4 Partner departure for traditional random approach under abnormal mode

In Figure 3.4, partner departure under abnormal mode in traditional random approach will end up with that no body knows the departure of partner 0. Hence, every time the new peer received a video chunk from the parent partners and after it sent back an acknowledgment message to the parent, the new peer will start up a timer, if no chunk is received from the parent partners until the timer expires, we assume parent partners was departed from the system, and the new peer will issue a request message with pre-defined certain information (i.e. peer d sequence number, IP address, channel, receiver, next chunk, partner number, the number of times and so on) to the tracker server to search one or more successor partners by carrying out standard operating procedure and establishing a sorted queue with information within request message.

This way will increase delay time comparing to normal mode, because tracker

server can not be notified immediately when the partner 0 departed from the system. If the new peer received a next video chunk from the parent partner before the timer expired, then we terminate the timer and send back an acknowledgment message to the parent partner and re-start up the timer.

The tracker server arbitrarily selects a peer from peer list to check if it have enough available upload bandwidth and watch the same channel and at least have the next chunk corresponding to partner 0 and add it to candidate partner list. When tracker server collects certain amount of information, then based on the information of the partner d and the rule, tracker server builds a sorted queue that is suitable for the new peer from the candidate partner list.

 The closest distance to this partnership (by the IP address).

 The match degree of the download and upload bandwidth.

Then tracker server chooses the top entry of the queue as successor of partner 0, then moves the pointer to the second entry of the queue, and issues a seek message to candidate successor s with certain information (i.e. Partner 0 sequence number, next video chunk, receiver (the new peer), the number of partners, the number of times and so on) and setup a timer, if the timer expires, we think this candidate successor was gone or has not enough upload bandwidth, then tracker server will re-choose another candidate successor partner from the top of the sorted queue and move the pointer to the next entry.

If this candidate successor partner (successor 2) exists and has enough upload bandwidth, it will send the next chunk (calculated from the peer d sequence number, partner number and round) to the new peer as partner 0 normally did and issues a update message to the new peer in order to refresh the IP address of the partner 0 sequence number which is kept in database of the new peer, then successor 2 issues a seek acknowledgment back to tracker server for reply, when tracker server receives this

acknowledgement message, it will issue a response message to the new peer to finish this procedure.

Figure 3.5 Partner departure for proposed approach on abnormal mode.

As Figure 3.5 depicted, under abnormal mode for our proposed approach, every time the new peer send back the acknowledgement message to the parent partners (partner 0), it will starts up the timer, once the timer expired, however, the new peer do not receive any video chunks from this parent partner (partner 0), then the new peer realized that the partner 0 has already departed from the P2P IPTV system. The new peer terminates the timer when it gets a new video chunk, and then resets the timer after sending back an acknowledgment to its parent partners. The new peer calculates out the successor of partner 0 (named partner 1) with several parameters (partner d, sequence number, and partner number) and previously defined formula that already mentioned in

assumption. The new peer issues a request message to partner 1 to replace partner 0.

The partner 1 does not need to check its own available upload bandwidth since it already has reserved certain amount of upload bandwidth previously by adjusting β parameter by programmer.

The partner 1 chooses a certain video chunks (calculated based on the partner 0 sequence number, partner number and the number of times) to pass to the new peer as the partner 0 usually did. The partner 1 also updates the new peer by refreshing the IP address of partner 0 sequence number that is recorded in database in new peer.

When the tracker server receives the request message sent from the new peer, it will perform the standard operating procedure and establish a sorted queue with information carried the request message (i.e. the sequence number of the partner 0, IP address, channel, receiver, next chunk, partner number, the number of times and so on), the tracker server issues a notification message (with same information) to the successor (chosen from the top of the sorted queue and move the point to the second entry), the successor definitely has the enough upload bandwidth to pass the video chunks sequentially to the new peer, it issues a terminate message to the partner 1 to get the next chunk sequence number in order to send the sequential video chunks to the new peer. Finally, the successor will issue a re-update message to refresh the IP address of the partner 0 sequence number to be successor which keeps in the database of the new peer.