Organization of the Thesis

The rest of this thesis is organized as follows. First of all, we describe the basic P2P application concept from file-sharing to IPTV streaming in Chapter 2. In Chapter 3, we describe our proposed approach in detail. In Chapter 4, we give a brief description of the OMNet++4.0 tool and evaluate our approach based on the simulation. Finally, conclusion of this thesis is described in Chapter 5.

Chapter 2 Introduction

In this chapter, first of all, we introduce some P2P applications and IPTV systems, tree-push and mesh-pull method and the related newest P2P IPTV push-pull methods.

2.1 Peer-to-Peer Network

2.1.1 Introduction to peer-to-peer model

Earlier in Internet application, client-server is the most popular model, due to its stability and ease of maintenance, but it still has several disadvantages, such as scalability problem, expensive bandwidth, single point of failure problem and bottleneck problem as time goes by and number of users grows. When the user population goes large, the problem becomes more serious.

In order to solve and improve this problem, P2P computing concept are proposed and applied to Internet applications. In P2P model, each peer play both server and client role, that is, every peer can upload and download file to/from other peers in order to find a more efficient way of utilizing peer resource, such as CPU computing power, memory, storage space and upload bandwidth. However, P2P model still encounters some problems which need to be solved or improved. In the following paragraph, we will introduce the P2P application, such as file-sharing, VoIP and IPTV streaming.

2.1.2 P2P file-sharing application

The P2P systems can be split into pure and hybrid model, pure P2P means no any server inside, and all the file transmissions are performed by peers alone. On the other hand, there are several servers that keep metadata information in hybrid P2P model.

Gnutella is the pure P2P model that use flooding method to issue request signal to all of

its connected peers in order to get the file that it wants. Freenet is another pure P2P model example. The pure P2P model is not a good idea, since it waste the Internet bandwidth resource and not very efficient.

Figure 2.1 Pure P2P model

In Figure 2.1, we can find that there is no any server in pure P2P model, this makes it easy to implement, however, it makes the system hard to maintain.

BitTorrent (BT) was started in 2002, it was a very popular system for file-sharing, and it opens its source code, hence everybody can edit it and create a new different version. In order to deliver the file efficiently, the torrent file is created, this file has metadata information and related tracker servers information, it helps the peer to find out its target file. From torrent files, we can contact a tracker server or several tracker servers to find the target files.

In BT model, every data will be split into smaller fixed size chunk, this made the transmission faster and use bandwidth efficiently. Further, every peer can retrieve

different chunks from different peers simultaneously.

Figure 2.2 BitTorrent operation procedure.

In Figure 2.2, we can understand how a peer retrieves chunk from other peers. First of all, a peer has to find the file torrent which contains some information, such as file name, file size, and related tracker servers IP address. According to this metadata torrent file, peer 0 will issue a request message to related tracker server, which then will send a acknowledgement back to the peer. The acknowledgement contains some information, such as which peers have this file, then peer 0 will issue a request message to peer 1 and peer 2, and peer 1 will send chunk 2 and chunk 4 to peer 0, and peer 2 will pass the chunk 1 and chunk 3 to peer 0. Thus, peer 0 has downloaded all the requested chunks from number 1 to 4 simultaneously.

We can understand the hybrid P2P model concept in Figure 2.3, there are several servers to help P2P system work properly, these servers do the tasks such as storing

every peer’s information and keeping the transaction on safety state. We can obtain other information such as which peer has which files from these servers.

Figure 2.3 Hybrid P2P model.

Another famous hybrid P2P model applied on file-sharing is Napster, Napster is one of the earliest P2P applications. It let everybody share its music through the Internet, however, soon after it started commercial operation, Napster faced the copyright law suit and quit from the market.

2.1.3 P2P VoIP application.

VoIP (Voice over Internet Protocol) is another popular P2P application, and Skype is the one of most wellknown example of the P2P VoIP. Comparing to traditional public VoIP standard such as SIP and H.263, Skype has a well scaling capability. There are several super node in the Skype, every peer depends on and connect to at least one super

node which can be connected to other super-nodes or peers. A peer plays a client role in the beginning, if the peer has powerful capablity, then the Skype system will promotes the peer to super-node role.

2.2 P2P streaming

P2P streaming is the most popular P2P application recently, user do not need to download the data completely as file-sharing does, hence it solves the free-riding problem, in which the user leaves the system right after it has already downloaded the data. The history of the solution of IPTV system is as follows:

2.2.1 Centralized server architecture

Centralized server architecture is the most intuitive way to realize an IPTV system.

However, it encounters the same problem as earlier mentioned client-server model. The video content may even overwhelm the Internet in this architecture, hence it is not popularly deployed.

2.2.2 IP layer multicast

The routers in IP layer multicast method is the key, it is designed to solve potential overwhelm problem and reduce the overhead of the servers in centralized architecture.

In IP layer multicast, a server only sends video data with multicast address, then the routers sends every copy destined to peers. However, the routers in network core belong to different ISPs, and users (peers) are not authorized to enable this function inside the routers. Hence this method does not work in real world.

2.2.3 P2P architecture

The well accepted IPTV solution is P2P architecture, because it reduces

dramatically sever load, and only increases peer load a little. In P2P IPTV system, every video data is split into smaller chunks, these severs only transfer the video chunks to partial peers, then these peers transfer the chunks to others connected peers. Tree-based and mesh-based are the most of the popular overlay construction in P2P IPTV system.

Overlay construction and scheduling algorithm are the key modules in P2P IPTV system, there are several studies to discuss the issue and propose solutions to achieve better quality of experience (QoE). Membership management, partnership management and peer adaptation are also the necessary functional modules in a P2P IPTV system.

2.3 P2P IPTV Overlay construction

2.3.1 Tree-based overlay

Single tree-based overlay is very easy to implement, every peer deliver the video data to its connected children peers immediately right after it received the data from its parent peers, hence dramatically reduce the delay. However, there is structure reconstruction problem after one or several peers leave. In Figure 2.4, we can clearly realize that leaf peers do not contribute the upload bandwidth.

Multiple tree-based overlays is designed to solve the above mentioned problem, the server divides the stream into several sub-streams for several sub-trees, and these sub-tree peers can deliver the sub-stream to each other. However, multiple tree-based overlays are more complex than single tree-based one in both implementation and maintenance.

Figure 2.4 Single tree-based overlay.

2.3.2 Mesh-based overlay

As Figure 2.5 shows, in mesh-based overlay, every peer takes a random connection to/from other peers and servers. Hence, unlike tree-based overlay, mesh-based overlay does not need to repair the overlay or reconstruct the structure after one or more peers leave. Pull mode is usually used in mesh-based overlay, that is, every peer issues a request to another partner to receive the video chunk according to the content of the buffer map that is exchanged between partners. Buffer map can tell us which chunks this partner has. Considering a new peer to join the P2P IPTV system, it makes a contact to the tracker server in the beginning to ask for some information, the new peer logins and selects a channel to watch, then tracker server give the new peer a peer-list that watch the same channel as the new peer does, the new peer chooses some peer from this peer-list as candidate partners. Then the new peer will connect to these candidate partners to make a partnership group. The new peer exchanges buffer map and video

chunks with these partners. Every peer can connect to video server and receive video chunks from it, too.

Figure 2.5 Mesh-based overlay.

2.3.3 Comparison of the mesh and tree overlays

There are several studies discussing the difference between mesh-based and tree-based overlay. Unlike mesh-pull systems, tree-push systems have better delay performance when

• The tree structure does not break down due to peer churn, and

• peers at the higher level of the tree have sufficient upload capacity to support the streaming of their children peers.

Tree-push method is still staying in academy research. However, mesh-pull method already has commodity for user to deploy, such as Cool-Streaming, PPLive, and

PPStream. In recent years, researchers take advantage of these two overlays into the new overlay model, push-pull, we will describe the detail in Section 2.5 later.

2.4 Scheduling and adaptation algorithm

Pull and push mode are used in P2P IPTV model, tree-based overlay usually use push mode to deliver streaming data from parent peers to its children peers right after they receive the video stream from their parents. In mesh-based overlay, pull, push and hybrid mode that combines pull and push mode can be used. Usually, mesh-based overlay use pull mode, such as CoolStreaming, PPLive, and PPStream.

Scheduling algorithm tells us which video chunk to send to which partner and which video chunk to request from which partner. Usually random method is used in source peer selection; however, there are several methods for chunk selection, such as the following:

1. Sequential: round-robin way, that is, choose video chunks from head to end.

2. Random: the easiest method to arbitrary pick up a chunk.

3. Rarest-first: to choose the rarest chunks in the local side. Used in CoolStreaming system.

Peer adaptation algorithm keeps the partnership working well. After a long time establishing partnership with other partners and exchange video chunks among partners and source servers, one have to search more suitable partnership for QoE improvement due to some partners leave or network backbone gets broken.

2.5 Push-pull architecture

The current P2P IPTV research is push-pull architecture, it combines the advantage

of the tree-push and mesh-pull architecture. There are several examples, such as:

– Cool Streaming: the push-pull version of cool streaming.

– GridMedia: tries to overcome the limitation of the DONET pull approach which request chunk in pull mode at start up and having nodes relaying chunk in push mode.

– PRIME: the new chunk have been advertised by parents during the last scheduling event and requested by children according to a global pattern of content delivery that minimizes the probability of content bottleneck among peers.

2.6 Introduction to QoE

In P2P IPTV system, we talk about QoE (Quality of Experience) instead of QoS (Quality of Service) normally mentioned in traditional network. QoE focus on

customer’s perspective to the system that vendor provide, it has several parameters:

1. Start-Up Delay

The time slot between one channel to another channel, the range of time slot

usually from 10 seconds to 2 minutes that dramatically longer than traditional television, there are several research paper to improve this problem.

2. Playback Lag

Due to the distance difference among peers, there is playback lag problem in the P2P IPTV system, playback lag means does not synchronization among peer’s experience, for example, some peers may watch a home run in live baseball game minutes after the real game.

3. Continuity

Continuity determine whether the video streaming is smooth enough, continuity index (between 0 to 1) can be used to measure, which is the number of video chunks that arrive before or on playback deadlines over the total number of video chunks. If the continuity index arrives 1, that means all of the video chunks have already arrived before the playback deadline.

Chapter 3 Proposed Approaches

Peer’s frequent departure is a very common event in P2P IPTV system, when we consider the situation that one or more peers are going to depart from the P2P IPTV system, the current traditional approach that arbitrarily chooses one or more successor partners via pre-defined complexity standard operating procedure with the information of departed partners by tracker servers will cost long recovery switching time (from interrupting the video chunk transmission to the recovery from new successor partners).

In the rest of following paragraph chapter, we proposed a method to reduce the recovery switching time and to fully utilize the upload bandwidth of all of the peers instead of high upload-bandwidth peers. Asymmetric network environment (upload bandwidth and download bandwidth of peers is different) is very common in the P2P IPTV architecture, we take it into account and use every peer’s upload bandwidth rather than only get chunks from high upload bandwidth peers.

3.1 Design Philosophy

In order to reduce long recovery switching time in traditional random approach, we propose an approach that chooses the local partners as temporary successor partners until it finds steady successor partners via tracker servers. The partner’s departure is categorized into normal and abnormal mode (un-expected departure).

3.2 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

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