Characteristics of the public peer

A public peer is defined as a peer who is able to accept unrecognized incoming packets in this paper. Since a peer who works behind the NAT may accept incoming

connections through proper configuration, definition of the public peers should not limit to ones who own a public IP address. A public peer here could be 1) a peer owns a public IP address and the incoming connections are not blocked by a firewall, or 2) a peer adopts proper port forwarding configuration while it works behind the NAT. There are many ways to make a peer able to accept incoming packet even the peer works behind the NAT. This can be done through proper configuration, which is setting the port forwarding rules. The port forwarding rules tell the NAT how the incoming packets forwarded to the private clients. UPnP [19] established the protocols for users to configure the port forwarding rules. Also, the user may manually configure the port forwarding rules.

Even if there exists mechanisms that turn more private peers into the public peers.

However, it is possible that a public peer may refuse to accept incoming connections at anytime and thus become a private peer. For ensuring capability of the peers, the repetition of the detection process is needed.

3.1.2 Public peer detection process & its protocol

The public peer detection process aims to detect if the peer is able to accept incoming packets. The process is performed when a peer is receiving a data request. We term the peer who sends the data request as the child peer, and the peer who receives the data request as the parent peer.

The detection process consists of messages that are requesting a listening port and confirming the availability of the port. Four messages are defined in the detection process. Peers indentify the messages with the messages name. The following explains the messages used in the detection process:

z REQP: The parent peer requests a listening port from the child peer by performing REQP. The child peer opens an arbitrary listening port upon it receives the REQP message. This method is initiated when the parent peer receives data request.

z ACKP: ACKP is the acknowledging message to the REQP. It contains the information of the listening port number which is generated by the child peer.

Normally, the port number will be an integer within 0-65535. When the child peer fails to initiate listening socket, the port number will be filled with -1.

Fig. 3-1. Public peer detection process protocol

z HELO: HELO is used to test the availability of the port requested in the REQP. It initiates a new session with the child peer, sends a HELO message, and waits for the response from the child peer.

z ACKH: ACKH is used to confirm the availability of the listening port.

Corresponding to HELO method, the child peer acknowledges the parent peer with the ACKH message. The parent peer then confirms the child peer as a public peer upon receiving the ACKH message.

An example of the detection process flow is shown in Fig. 1. The process starts when a peer sends the data request to another peer. The parent peer first sends REQP message to the child peer for requesting a listening port. The child peer then initiates the listening socket and responds the parent peer with the ACKP message. The parent peer checks if the port number in the ACKP message is legal or not. The legal port number will be located in the range of 0-65535. Otherwise, the detection process terminates and the child peer will not be identified as a public peer. If the process continues, the parent peer tests the port number provided in the ACKP message. The parent peer initiates a new session and sends the HELO message to the child peer. If the child peer receives the HELO message, it will respond with an ACKH message. The detection process terminates when the parent peer receives the ACKH message timely. Note that the child peer may works behind a NAT, which drops incoming packets silently. Therefore, the

parent peer sets a timer for the responding message. If the HELO message is not responded timely, the detection process terminates and the child peer is identified as a private peer. To make a brief conclusion, a child peer will be identified as a public peer if the port number in the ACKP message is legal and the ACKH message is timely responded.

3.1.3 Priority request queue

In addition to the public peer detection process, we prioritize the data requests. The data requests from public peers hold higher priority than those from the private peers.

Each peer prepares two queues for storing the data requests from the public peers and from the private peers respectively. In our mechanism, a peer serves the data requests from the public peers before serving the data requests from the private peers. In other words, a peer checks the queue for the public peer first when it is able to serve data.

We may make the public peers preempt the ongoing transmission of private peers.

However, transmission preemption, which may lead to data starvation, is not adopted in our mechanism. The data starvation may occur and leads to performance degradation. If the preemption is adopted in such a system, the public peers may join the network and send data requests in any time. In this case, private peers may keep waiting for public peers to complete their transmission. This is obviously a data starvation and is negative to the P2P system performance.

3.2 ISP-Friendly Scheduling

The ultimate goal here is to build connections with partners located in the ISPs that do not charge for the cross-ISP traffic. However, the economics of ISP relationship remains unclear due to the ISPs are not willing share the relationship among them. That makes people do not know how the connections incur payment. To reduce the crossing boundary payment, the best strategy here is make all the connection restricted in the same ISP [16]. Whereas such a restriction to the connections degrades the performance, we are seeking an alternative solution.

Our ISP-friendly mechanism reduces cross-ISP traffic by considering the ISP origin while performing data scheduling. In the rarest-first segment scheduling scheme, it is possible that multiple rarest segments exist. In this situation, a peer randomly chooses a segment from the rarest ones and thus results in the traffic randomness. We suggest that a peer to schedule a data source with considering the ISP origin of the data source.

Besides, a peer should schedule a transmission with the domestic peers as much as possible. This can be done by sorting the partner list before scheduling. Table 1 show

TABLE I. THE PROBABILITY FOR FINDING A LACKING DATA SEGMENT IN A PARTNER LOCATED IN THE SAME ISP

File sharing system Streaming system

Probability 95.8% 59.5%

the probability of seeing a lacking data segment that is hold by a domestic partner while performing scheduling procedure in our simulation. Theoretically, the cross-ISP traffic can be reduced to 4.8% for a P2P file sharing system and 40.5% for a P2P streaming system. However, the available bandwidth sets the limit for the transmission. Though the proposed mechanism may reduce the cross-ISP traffic, the question remains is whether such a peer selection scheme will also benefit the users. Since the transmission capability remains unchanged, the performance of the system should not be changed.

Simulations are conducted for further verification.

3.2.1 Identification of domestic peers

We use the nslookup service for querying the ISP information of the peers by the IP address. Nslookup service was originally designed for querying the ownership information of the IP address. It also can be used to query the ISP origin of the IP address. When we use the nslookup service, the IP address is sent to the nslookup service server and the information of the IP address returns. One of the information is the netname, which is the abbreviation of the ISP. The abbreviation of each ISP is unique and can be used as the identifier of the ISPs. Therefore, the domestic peer is identified by comparing the netname of the peer.

3.2.2 ISP-aware rarest-first segment scheduling

Our scheduling scheme is modified from the state-of-the-art rarest segment first scheduling scheme. The rarest-first scheduling sorts the number of the segments and schedules the transmission for retrieving the rarest ones. This scheme guarantees high diversity of the segments. In particular, it prevents reappearance of the last segment problem and of the rare segment problem. However, our observation shows that there are multiple rarest segments in the network and the transmission is scheduled to randomly retrieve one of them. While some of these rarest segments may be retrieved within the same ISP, we can make the traffic more ISP-friendly by requesting these segments first.

We propose an ISP-aware rarest-first scheduling scheme which schedules the domestic transmission first. The algorithm is illustrated in Fig. 2. In our method, the

Fig. 3-2. ISP-friendly scheduling algorithm

scheduling procedure begins with discriminating the domestic peers. Then we sort the segment list by the number of the segments to find the rarest segment. After the sorting, the peer sequentially asks the domestic partner for the lacking data segments. The transmission will be scheduled if any lacking data segment exists. It is possible that the domestic partners do not have the data segments requested. In this situation, cross-ISP traffic occurs for retrieving these data segments. However, other peers may request the peer who just made cross-ISP traffic for the lacking data and reduce the cross-ISP traffic.

Chapter 4 Simulation

The author has conducted a series of simulations to evaluate how scheduling policies, public-first delivery and ISP-friendly scheduling affect download time for P2P file sharing and video continuity for P2P multimedia streaming system. The simulations are round-based in that, for each round, every peer completes the scheduling computation and data downloading at once.

4.1 Simulation Model

In the simulation, unless otherwise specified, every peer will perform the following actions in every single round: (1) Receiving buffer map of other peers, (2) Sorting the segment availability and request data by rarest first, (3) Randomly choosing a data source from those who holds data segment needed, (4) Respond incoming requests if any.

4.2 Effect of Public-First Delivery

To examine the efficiency of the public-first delivery policy, we implement the FIFO policy for comparison, in which, the data requests will be processed based on the time. Using the public-first policy, a peer will process the data requests from private peers only after requests from public peers are fulfilled.

To evaluate the file download time for a P2P file sharing system, we configure the

simulations as follows. There are 101 peers in the simulation, including a source peer and 100 peers to download a file from the source peer. All peers stay on throughout the simulations. The file is divided into 200 segments. The source peer is capable of serving 10 segments each round. The other peers are capable of serving 3 segments and requesting 6 segments each round. Every peer is connected with every other peer.

Before a peer requests a segment, the peer solicits the segment availabilities from other peers and determines the segment to request next based on the above mentioned rarest first policy. When a peer is requesting a segment, it will search by the rarest first order and ask its neighbors sequentially. This makes the peer may not fetching the rarest segment when it holds all the rarest ones. However, this is close to how the real peer-to-peer transmission systems work.

The performance metric in this simulation is the elapsed time to complete the file transmission. We vary the percentage of public peers in the network and see how the proposed policy scales to the amount of public peers in the network. Fig. 4-1. is the simulation result.

Before a peer requests a segment, the peer solicits the segment availabilities from other peers and determines the segment to request next based on the above mentioned rarest first policy. Fig. 4-1 shows the performance of P2P file transmission using public-first policy vs. not using the public-first policy. Since public-first delivery policy has better utilization on upload bandwidth. We can see the public-first policy reduces Fig. 4-1. Performance plot of peer-to-peer file sharing system simulation for different

elapsed rounds by about 20%. The benefit of public-first policy is significant even when the percentage of public peers is low. The performance improvement comes from the public-first makes data segments distributed effectively.

To evaluate the continuity of the video stream, we extend the setting to capture operations of a P2P multimedia stream broadcasting system. Unlike P2P file transmission systems, peers in the multimedia streaming system will not hold entire downloaded file. Peer will, usually, maintain a buffer that stores partial streaming data.

With streaming buffer, peer will not store entire file that may take hundreds of MB.

A larger amount of buffer benefits the quality of video playback. We have configured in this set of simulations that every peer holds a 60 segments buffer space.

Note that the video is divided into segments and each segment contains one second of video. When peer begins playing, it waits 20 rounds of initial buffering. The simulations run for 1000 rounds. Other settings are like those in the file sharing simulation. Segment continuity is considered the main performance metric in the simulation. Segment continuity, which is called continuity index in [6], indicates the percentage of timely received data segments. A higher score means a better video streaming quality. Figure 4-2 has shown the simulation result of a peer-to-peer streaming system. We may see that the public-first delivery does not benefit in terms of video segment continuity index. In Figure 4-3, the average buffer utilization shows the

public-first delivery benefits buffer utilization. However, the average continuity index doesn’t improve much. More simulations were conducted for explanation of this phenomenon.

Fig. 4-2. Performance plot of peer-to-peer streaming system simulation for different

percentage of public peers

It might be puzzling that the fact of using public-first delivery or not does not benefit peer-to-peer streaming systems performance. The reason comes from how the peer-to-peer system performs scheduling. In this simulation, when a peer is scheduling a data source, it will search its neighbors they hold the segments it lacks in a rarest first fashion. That makes the transmission happens when the requested peer has the ability of uploading a segment and holds the segment. In the previous simulation, the buffer size is 60 segments, which is large enough for a requesting peer finds a segment that it lacks in. That makes the performance bottleneck is only the available upload bandwidth, which remains unchanged in both scenarios.

Fig. 4-3. Average buffer utilization of peer-to-peer streaming system simulation for

different percentage of public peers in the network

To illustrate this, we may think of how the peer-to-peer networking transmission works. The transmission in peer-to-peer networking systems fails when the data provider does not has the upload bandwidth or the requested data. Using public-first delivery make public peers has better chance of getting data. However, the performance is limited by available upload bandwidth in the system.

The author has conducted simulations that are illustrative to how the public-first delivery affects the peer-to-peer streaming system performance. The reason of having identical continuity index comes from how the scheduling works. The peer will request a segment which is short of. The requesting peer can always find a deficient segment that is hold by another public peer when the buffer size is large enough. That is, when the buffer size is small, the video segment cannot be distributed effectively. When the public peer cannot receive video before the segment is shifted out of the buffer, it obviously cannot distribute the segment. Public-first, by definition, sends video segment to public peers first. That makes public peers able to contribute their bandwidth as soon as possible.

Hence, using public-first would not suffer from the performance degradation brought by smaller buffer size. Figure 4-4 has shown the effect of varying the buffer size.

In this buffer size varying simulation, the percentage of the public peers is 20%.

Previous simulation result shows that when the buffer size is large (60 segments), the Fig. 4-4. The effect of varying buffer size

Fig. 4-5. Performance plot of peer-to-peer streaming system simulation for different

start-up time of private peers in the network.

continuity index is around 0.68. Reducing buffer size results in continuity index decreasing. We may see the continuity index drops dramatically when the buffer size shrinks. The reason comes from that it takes time for public peers to get the data and forward to others. Since the public-first delivery sends the data to the public peers first, the public peers may contribute their bandwidth as soon as possible. This makes performance difference in terms of continuity index.

The author cannot stop wondering if there are other scenarios that the public-first benefits peer-to-peer streaming systems. In the previous peer-to-peer file sharing system simulation, public-first outperforms 20% in terms of file transmission time. That may indicates if the sliding window is not moving, public-first delivery has better transmission efficiency. Inspired by this, the author has conducted simulation that is changing the start-up time of private peers.

In Figure 4-5, the start-up time is changed to see if the public-first benefits. In this simulation, the start-up time for public peers is fixed to 5 rounds and the start-up time for private peers varies. The buffer size for each peer is 60 segments. The percentage of public peers is 20 percent. The goal for this simulation is to see if delay the start-up time of private peers benefits.

In this simulation, the performance of using public-first delivery is better by around 3-5% in terms of continuity index. The reason for this phenomenon comes from

the public-first delivery has better delivery efficiency while the sliding window is not moving. Due to the start-up delay is relatively small to the entire streaming playback time, the improvement is relatively small.

4.3 ISP-Friendly Scheduling

For this set of simulations, we assumed that there are 4 ISPs and 25 peers in each ISP. 12 out of the 25 peers in each ISP are the public peers and the others are the private ones. The source peer is not categorized in any ISP. To simulate ISP-friendly scheduling, every peer will sort the neighbor by the ISP information. Other simulation settings remain the same as the previous sets of simulations. Traffic between ISPs is logged to see if the traffic is well-controlled.

Traffic between ISPs is logged in the tables below. Numbers in the tables

Traffic between ISPs is logged in the tables below. Numbers in the tables