On the Impact of Network Address Translation on Locality-aware P2P Live Streaming Systems

Transcription

1 On the Impact of Network Address Translation on Locality-aware P2P Live Streaming Systems Mohammad Z Masoud, Xiaojun Hei, Wenqing Cheng Huazhong University of Science and Technology, Wuhan, China engmohammadmasoud@gmailcom, heixj@husteducn, chengwq@husteducn Abstract More that 7% of all Internet hosts are behind network address translation (NAT) devices In this paper, we study the impact of the NAT devices on application layer traffic optimization (ALTO) schemes NAT brings forth difficulty if not impossible for peers to connect to one another, which may lead sever performance penalty of P2P applications Most localityaware P2P systems only consider network location such as autonomous system (AS) number In this paper, we first demonstrated that peers may be expelled from the system with a high probability in P2P live streaming systems because NAT devices degrade the peer s capacity for contributing upload bandwidth We proposed a simple model to compute the theoretical upper and lower bounds for the number of displaced peers We also propose a simple peer selection algorithm with the NAT consideration in mind to build a non-random peer list that reduces transit traffic, increases peer connectivity and minimizes the playback start-up time for ALTO schemes We conducted a ns2 simulation study to evaluate the performance of the proposed algorithm Based on multiple simulation experiments, we demonstrated that the proposed algorithm decreases the number of expelled peers while it reduces the start-up delay of peers and reduces the interdomain traffic Keywords: network address translation, peer-to-peer; live streaming; Internet service provider; locality awareness I INTRODUCTION Peer-to-Peer (P2P) live streaming systems are live Video, life or on-demand occupies more than 7% of P2P Internet traffic [1] Application layer Traffic Optimization (ALTO) schemas have been proposed to reduce the load of P2P systems This includes live streaming on ISP s inter/intra-domain traffic [2] Optimization should increase the efficiency of these applications while decreasing inter/intra-domain traffic loads This is considered a win-win solution Simulation studies of optimization schemas for P2P file sharing systems have proven promising [3], [4], [5] In P4P [4] approach, the author showed that a collaboration mechanism reduced the download time (Increased the efficiency) by 4% while reducing transit traffic Real trace results for optimization have lead to different opinions [6], [7] They have shown that such mechanisms can decrease the efficiency of P2P file sharing systems by increasing download time ISP s may use caches to reduce the download time to obtain the required output [7] Why is there such a difference between trace data and simulation results? The answer is the parameters Simulation studies do not consider all real life parameters When researchers start to consider a new parameter, new unexpected results can become manifest Upload capacity and peer distributions are two parameters that were studied in [6] The author has shown that under normal distribution AS s both homogeneous configuration of upload and average upload capacities are higher than the video rate from which both P2P and ISP can derive benefits For Internet parameters with heterogeneous upload capacity, skewed peer distribution and unpredictable upload capacity will benefit ISP s rather than P2P s and this can have a negative effect upon the latter In this work we will study another important parameter that can reduce the connectivity of P2P live streaming systems, that is, the Network Address Translation (NAT) parameter NAT, has been used to solve the shortage in IPv4 address space (connectivity) as well as to hide the service provider s internal network structure (security) [8] NAT solution is popular on the Internet More than 73% of Internet users use NATing [9] NAT is suitable for the Internet s structure or the client server approach Clients initiate connections to servers with static public IP addresses These servers send responses to clients using their dynamic public IP addresses This is not the case with P2P systems A peer is a hybrid between a client and a server; it requests services and responses to requests Peers can have a public IP address without NATing, which is termed (opened or public) or a private IP address mapped to the public one after NATing Such an address is termed (private) The connection between peers can take the form of one of four types: private-to-private, public-to-public, privateto-public and public-to-private Methods have been proposed to solve private-to-private connectivity because it is the one that will most probably occur These methods cannot provide connectivity for all types of NATing[1] This parameter has a tremendous negative effect on connectivity in live streaming systems In file sharing systems, it can increase the download time because of the reduction in the number of donor peers but in live streaming, it expels peers out of the system In any live streaming system, the peer starts to join by sending a message to the source The source answers with a peer list The node then starts to contact these peers to obtain the full stream If it cannot obtain the full stream, it tries other peers in the system with a second connection round The number of rounds depends on the P2P streaming system s design With an increasing number of rounds, the probability of finding suitable parents increases including the playback start-up delay time Zattoo [1] for example, uses three rounds before the peer stops trying When the peer stops trying, we call it expulsion In this paper, we show that in any live streaming network

2 there is a high probability that, peers will be expelled We introduce theoretical upper and lower boundaries for the number of kicked-out peers We also propose a novel and easy to implement parent selection algorithm to build a non-random peer list that reduces transit traffic, increases peer connectivity and diminishes playback start time delay by reducing the number of rounds This mechanism tries to keep the number of expelled peers as close as possible to the lower boundary We found that neighbor selection algorithms that depend only upon AS awareness are not enough for live P2P streaming system We will also show that there is a trade-off between traffic locality and peer connectivity The rest of this paper is organized as follows We end this section by describing related works done in this area Section II, introduces the theoretical boundaries of the expelled peers and ends with the algorithm that reduces this number We conducted a simulation study to validate our proposed P2P streaming architecture and then analyzed the simulation results in Section III Finally, we conclude this paper in Section V A Related Work To develop the rationale for this work, we had to consider previous research in P2P measurements that have studied NATing The real traces from Zattoo s system show that peers can be expelled from the system because of NATing issues [1], [11] These works also show the percentage of NAT types in Zattoo s network (in Europe) and the popularity of symmetric NATing In [12], the author studied P2P VoD systems The author proved the popularity of symmetric NATing in these systems also In [13] the author completed a measurement study on a P2P file sharing system The author demonstrated that the percentage of each NATing type can depend on a particular country (location) This result shows that a locality awareness option without awareness of NATing can lead to reduction of connectivity among peers In addition, the author demonstrated the popularity of UDP disabled and symmetric NATing, which are not P2P friendly Our work does not propose a new method to allow peers or nodes behind NAT devices to connect with each other, such as hole punching [14] or NAT traversal [15] This work proposes a way for a peer to find its NAT matching peers to allow hole punching to work correctly To understand this concept, hole punching uses the idea of a third parity server to initiate the connection between peers and leaves them to exchange data by themselves This schema is easy to implement but it cannot be used to connect two hosts behind symmetric devices Our method proposes a way to construct the peer neighbor list by considering peers NATing types In this way, peers can easily find their NAT matches Other methods have been used to solve the NAT mismatch problem, for example relays with public IP address stay in the middle until the termination of the communication channel between the peers [16] This method is famous in P2P VoIP world [17] In [18], the author studied the effects of NATing relay nodes on traffic locality and transit load He proposed a simple algorithm to select relays from the same domain Avr Upload Speed 2R/5 R/2 4R/5 R 2R Upper boundary Lower boundary Percentage of Kicked out Peers Fig 1 Kicked-Out Peer Percentage to the Avg Upload Capacity in order to reduce transit traffic Unfortunately, these relays cannot be used with P2P live streaming for two reasons: first, the video rate can consume the upload capacities of relay nodes and make them useless for many other nodes Secondly, any online node in the P2P streaming system is actively watching (nodes cannot be online and inactive like Skype), which means it uses its entire upload and download capacity for itself This means that, peers with symmetric NATing cannot connect to one another in live streaming systems Many schemas have been proposed to build a peer neighbor list These solutions considered the reduction of inter/intradomain traffic or peers locality as the main point but have neglected their effects on the performance of P2P systems For example, Zattoo uses an AS-aware method to build the neighbor lists in its system However, [11] shows that peers can expelled from Zattoo network because of NATing For our best knowledge, no one has studied NATing type as a parameter to build neighbor lists until now Finally, in [19] the author demonstrated the effect of NATing on P2P file sharing The model demonstrated the probability that a peer can be expelled from a P2P networks Unfortunately, this model is not useful for our work for two reasons: first, this research assumed that there are two kinds of peers namely, public and NATed NATed peers can only connect to public peers while the latter can connect to both kinds This is not the fact as seen in table I Secondly, the researcher s model did not construct to study the effects of NAT configurations (NAT types) on the system It studied only the effects of NATing II THE PROPOSED SYSTEM One main target of our algorithm is to diminish the number of expelled peers To do this we have to predict the theoretical highest number of peers that can connect to the system under the NATing percentages and average upload capacities of the peers in the system This section begins by deriving the boundaries of expelled peers The proposed algorithm is then presented, which attempts to reach the lower boundary

3 Avg Upload Speed 2R/5 R/2 4R/5 R 2R Lower Boundary Upper Boundary Avg Number of Combination Tries with Zero Kicked out Peers Fig 2 Zero Kicked-Out Peer Percentage combination tries to the Avg Upload Capacity TABLE I NAT CONNECTIVITY Type name Type Open 1 Full Cone 2 IP restricted 3 Port restricted 4 Symmetric 5 UDP disabled 6 A Expelled Peers boundaries To prove that NATing can expel peers from P2P live streaming system, we need to understand how this can happen Four types of NATing can be found: Full Cone, Port Restricted, IP Restricted, and Symmetric In P2P live streaming systems, peers can be NATed with one of these four types plus another two configuration options: Open (without NATing) and UDP disabled Table I shows the ability to establish a connection among these types From the table we can observe that even with NATing solutions, such as, NAT traversal, not all NAT types can connect to one another What, however, is the probability of this scenario? To answer this question, we wrote all possible combinations of NAT configuration percentages that any network may have We used the traces from [1], [11], [12], [13] as constrains to write only the possible percentages combinations To anneal our prediction, we used five different average speed classes 3,764 different possible combinations of NAT percentage scenarios were constructed We used C language to write a program that construct random pairs of types Each pair, simulates a connection between any two NATing types The output of any pair, has one of two status outputs: true or false False status means that peers from these NAT types in this pair cannot connect with each other and one of them will be expelled We used 1 runs to create 1 random possible ways for each type to find its match We done this in each one of the combination that we created to find the scenario with the highest connected peers (lower boundary) and the scenario with the lowest connected peers (highest boundary) Within our theoretical boundaries, we used five NAT configurations (port restricted and IP restricted are the same in our model depending on table I) To predict the minimum theoretical number of peers expelled in a system, peers with open configurations should connect with UDP disabled peers in a higher priority and vice versa Peers with symmetric NATing must connect with full cone peers as a first priority then with open peers Full cone peers must connect with any type except open configuration peers and themselves For the restricted configuration, (IP or port) peers can connect with themselves as a first priority then with other types The percentage of IP restricted is always high [1], [11], [12], [13] If peers follow this schema, the number of expelled peers will be at a minimum We name it the Lower Boundary Algorithm 1 To obtain the upper boundary, which is the worst case, we found that every type of NATed peers must connect only with itself In such a case all UDP disabled and symmetric NATed peers will be expelled with other peers depending on the average upload capacity We found that from these 3764 different combinations of NAT percentage in any network with average upload capacity equal to half of the video rate, only 14% of these tries have 1% connected peers Fig 1 shows the percentage of expelled peers with different video rates This figure shows that the upload capacity can decrease the number of expelled peers but cannot eliminate it Fig 2 shows number of tries where no peers were expelled From this figure, we can conclude that for low average upload capacities the probability of having no expelled peers is approximately zero for random selection and high for priority selection B The Algorithm Our proposed algorithm converts the random selected list to a prioritized one depending on the AS number and the NATing type as in Algorithm 1 The algorithm starts to check the AS number of the new joining peer and chooses all peers from the same AS Subsequently, the algorithm selects the best peers depending on the NATing type If the peer has a disabled UDP configuration, the list will consist of Open Peers only (without NATing) If the peer has a symmetric NATing, the list will consist of Cone NATing as well as Open Peers with higher priority for the former If the peer is restricted (IP or Port), the list will consist of restricted (Port and IP) peers and they will have a higher priority than other types If the peer is opened, the list will consist of any type except open peers The UDP disabled peers in the list will get a higher priority Finally, if the peer is Cone NATed, the list will consist of symmetric and restricted peers only with a higher priority for symmetric ones If the list became full, the streaming provider server will send it If the list did not complete, the streaming server will fill the rest of the list with peers from different AS s after checking their NAT types This solution will increase the ability to find the best neighbors from the first round, which will diminish the playback start time This solution will reduce transit traffic and increase connectivity Unfortunately, the reduction in transit traffic will not offer

4 transit load reduction similar to the reduction of the solutions that depend only on AS-locality awareness but it will reduce the number of expelled peers to the theoretical low boundary and reduces the start up time From [13], we can see that there is a relationship between the location and the NATing distribution This can lead to reduction of peers conductivities under AS-locality awareness in some locations or domains and to an increasing in others Considering NATing as a parameter when construct the neighbor list, will allow the system to have a balanced peers connectivity in all domains Algorithm 1 The Theocratical upper bound algorithm for Kicked Peers P (i): Peer with i NATing type R: Video Rate in Kbps U p(i) : upload capacity of a Peer with NATing type i i: NATing configuration 1=open, 2=port restricted, 3=symetric, 4=UDP disabled K: Number of kicked out Peers for all Nodes in the sameas do if ΣU P (1) >= (ΣP (4) R) then K = Available = ΣU p(1) (ΣP (4) R) if (ΣU P (2) + Avalible) >= (ΣP (3) R) then if ΣU P (2) >= (ΣP (3) R) then K = Available = Available+(ΣU p(2) (ΣP (3) R)) else K = Available = (ΣU p(2) +Available) (ΣP (3) R) end if else K = K + ((ΣP (3) R) ΣU p(2) ) end if else K = K + ((ΣP (3) R) ΣU p(2) ) end if end for III THE EXPERIMENT We used NS2 simulator [2] in our experiment A pull-push streaming protocol was employed We used a pull-push system for two reasons: first, tree based system with high streaming rate creates many nodes without children peers Second, the mesh topology is good but it has a huge overhead and as we have recently experienced in the last few years the most wellknown mesh system (coolstreaming) has adopted a pull-push approach called (coolstreaming+) For our comparisons, we have implemented three algorithms to construct the neighbor list: the random, the AS-aware and the NAT aware algorithms In the AS-locality aware algorithm the list is constructed depending on the AS number In NAT aware algorithm, the list s construction depends upon the algorithm that we have discussed in this paper In the next section, we will discuss the streaming protocol that was implemented to be used in NS2 simulator A The Streaming System The streaming system consists of peers and a streaming server When a new peer joins the system, it sends a request to the server which in turn answers with a list consisting of 2-5 peers When the peer receives the list, it sends requests (to obtain the whole sub-streams lists) to the above number of peers If the NATing type between the two peers allows them to connect, the peer then answers with a message that contains the latest sequence number for each sub-stream If the NATing does not allow them to connect, the peer will not answer The peer then selects the parents depending upon the sequence number Subsequently, the peer sends a joining message to these nodes with the sub-stream number If the peer is unable to obtain the whole stream from its connected peers, it will ask for a new list from the server (another round) When the peer receives the streams, it checks the quality of the system every five seconds If the quality of any sub-stream is less compared to others, the peer disconnects the sub-stream and asks for the disconnected sub-stream from another parent If the quality remains the same for three rounds, the peer disconnects the whole stream and asks for a new list from the server B Topology and parameters Four AS s were located and connected to each other via a backbone as in figure 3[6]The number of peers in the first AS is 1, the second 2, the third 3 and the fourth 4, which gives 1 peers in total The effective upload capacity of these peers was chosen based upon a normal distribution from 12 to 65 Kbps The NAT configuration we used in our simulation was similar to the one in [11] Five hundred peers tried to join the system in the first second After 1 minute the remaining peers connect The rest of simulation parameters can be found in table II AS 1 1 Peers AS 3 4 Peers Inter-connection Streaming Server Fig 3 AS 2 2 Peers AS 4 3 Peers Simulation Topology In the second configuration we changed the upper boundary of the upload speed from 65 to 1 kbps We kept the rest of the parameters as before IV RESULTS The performance metric we used is divided into two categories One category is for ISP Measurement while the second one pertains to the P2P system Number of connected peers,

5 TABLE II SIMULATION PARAMETERS Definition Value Routers 2 PoPs 4 Video Rate (R) 5Kbps Peer 1 Video Duration 5 min Sub-Streams 1 Channels 1 Server BW 45Kbps playback start time including its Stability and the number of join messages are the metrics to measure the effects of P2P systems Transit in, out and the number of exchanged packets in the same domain are the metrics to measure the load on the Internet Service Provider The number of connected peers at the theoretical upper and lower boundaries was counted The connected peers were measured using the simulation and the boundaries were computed using the algorithm as in Fig 4 In these figure we can observe that the theoretical lower number of kicked out peers is 2% for both the random and the AS-aware algorithms and 22% for the NAT-aware algorithm We can observe in the figure that the practical number of kicked out peers in the NAT aware algorithm is 265% which is close to the theoretical boundary For the algorithm the expelled peers percentage is 368% and for the upper boundary it is 467% which shows that 368% is in the middle between the two boundaries In the AS-aware algorithm the number of expelled peers produced the highest value of 544% which is very close to the upper boundary of 56% Avg Numbr of connected Peers (%) High Boundary Number of Connected Peers Low Boundary Neighbor List Construction Algorithms Fig 4 Avg Number of connected Peers In Fig 5, we measured the effects that pertain to the second AS which has 2 peers From this figure we can conclude that the decreasing of transit traffic in, out and the maximum number of exchange packets in the domain is the optimum for the AS-aware algorithm For the NAT-aware algorithm, the reduction is higher than the Algorithm but it is higher than the Locality Aware one The AS aware reduced of the transit traffic by 54% but for the algorithm the corresponding reduction was 35% and this represent a tradeoff between both algorithms Avg throughput "MB" Transit In In Domain Exchanging Transit Out Neighbor List Contruction Algorithms Fig 5 Effects on ISPs Fig 6, shows the playback start time of the peers From this figure we can observe the stability of the system with the NAT-aware algorithm Stability here means that all peers playback start time is around the average playback start time In the figure the scattered points of both the random and the AS aware algorithms show that our algorithm is more stable than both of them In the figure we used 1 as start time for nodes that tried all the simulation times to connect but they failed to do so CDF As Aware Playback Delay (S) Fig 6 Stability of the Algorithms As we said before, upload speed is one of the constraints that we discovered Therefore, we changed the range of the upload speed and measure the number of kicked out peers, start up time and the average number of join messages Fig 7, shows the number of connected peers against upload speed As we can observe, with the increasing of upload speed the number of connected peers also increases but we did not reach 1% and as before, the AS-aware algorithm obtained the lowest connectivity of the three algorithms We also can observe that with our algorithm a higher number of connected peers can be found even with less upload capacity of the peers Fig 8 shows the average start up time of the whole system Without doubt our protocol has the lowest average upload time for two reasons, first less number of rounds to connect as we will observe in Fig 9 Secondly, NAT-aware algorithm build a full useful list not like the other algorithms which send a list

6 Percentage of Connected Peers Avg Playback delay (S) Fig 7 Effects of upload speed Fig 8 Avg Start-up Time of the Whole System with percentage of useful peers Fig 9, shows the average number of rounds that peers need to join the system By reducing this number we are decreasing the playback start time and the overhead of the system Our algorithm has decreased the average join messages but this number increased with the reduction of the upload speed Most of the peers in our system uses only one round Peers that did not connect to the system have increased this number which in turn increased the average number Avg # of Join Messages Sent from Peers Fig 9 Avg number of Join Messages Fig 1, shows the average playback start time of nodes with UDP Disabled NATing We can observe that the and the algorithms did not reduce or even effect the playback start time of peers with these NATing configurations Another misleading conclusion than can be obtain from this figure is that the playback start-up time decreases when the average upload rate decreases This reduction in playback startup occurs because the number of connected peers that have been expelled from the system increases with the reduction of average upload speed This lead to only few connected peers of this type that connected in the beginning Avg Playback Start up Time (S) Fig 1 Avg Playback tart-up time of Peers with UDP-disabled NATing Fig11 shows the average playback start-up time of symmetric Nating This figure demonstrate that our algorithm can reduce this start-up time more efficient than AS aware and random algorithms Another observation can be concluded from Fig11 and 1 that the start-up time of symmetric NATing peers is less than UDP disabled NAting peers even when we use our algorithm The reasons behind this are: first Symmetric NATing can connect with two types of NATing unlike UDP Disabled only one Secondly the percentage of Port Restricted NATing is higher than Open NATing Our algorithm tried to keep the average playback start time close as possible to the average start up time of the network Avg Playback Strat up Time (S) Fig 11 Avg Playback tart-up time of Peers with Symmetric NATing V CONCLUSION AND FUTURE WORK NATing can make it difficult, if not impossible, for peers to connect to each other In live streaming systems, peers can be expelled as a result

7 Locality aware solutions replace the random peer list with a selection mechanism that depends on the AS number of the peers when constructing neighbor lists In this paper, we have shown that the AS-aware algorithm can provide benefits to ISPs and harm P2P live streaming system AS-aware algorithm can satisfy ISPs need for reducing inter/intra-domain traffic with no benefits for P2P live streaming systems, when it is used with a high average upload capacity We also showed that in any live streaming network there is a high probability that peers will be expelled We introduced theoretical upper and lower boundaries for the number of expelled peers We also proposed a novel and easy method to implement a selection algorithm to build a non-random peer list that reduces transit traffic, increases peer connectivity and diminishes playback start-up time Our proposal tries to keep the number of expelled peers as close as possible to the lower boundary We found that neighbor selection algorithms that are dependent upon AS numbers are not enough for P2P live streaming systems Our simulation study also shows that there is a trade-off between the reduction in transit in the network and the number of connected peers Our algorithm reduced transit traffic but not to the extent achieved by the AS aware algorithm We can conclude that these solutions have limits in order to keep both P2P providers and ISPs satisfied ACKNOWLEDGEMENT This work has been in part supported by the NSFC under Grant No and the Technology Support Plan of the National Twelfth Five-Year-Plan of China under Grant No 211BAK8B1 REFERENCES [1] K Kerpez, Bandwidth Reduction via Localized Peer-to-Peer (P2P) Video, OFC, 29 [2] V Hilt, I Rimac, M Tomsu, and E Marocco, A survey of research on the application-layer traffic optimization problem and the need for layer cooperation, IEEE Communications Magazine, august 29 [3] X Weng, Y Hongliang, S Guangyu, C Jian, W Xu, S Jing, and Z Weimin, Understanding Locality-Awareness in Peer-to-Peer Systems, in IEEE ICPP, 28 [4] H Xie, Y R Yang, A Krishnamurthy, Y G Liu, and A Silberschatz, P4P: provider portal for applications, in ACM SIGCOMM, 28 [5] C David and B Fabián, Taming the Torrent: a practical approach to reducing cross-isp traffic in Peer-to-Peer systems, in ACM SIGCOMM, August 28 [6] Lehrieder, F Oechsner, S Hossfeld, T Despotovic, Z Kellerer, and M W Michel, Can P2P-users benefit from locality-awareness? in IEEE P2P, Aug 21 [7] IETF, China telecom ALTO/P4P trial, 29, [8] I Beijnum, IPv4 Address Consumption, The Internet Protocol Journal, 27 [9] M Cadaco and MFreedman, Illuminati Opportunistic Network and Web Measurement, Sep 27, [1] H Chang, S Jamin, and W Wang, Live Streaming Performance of the Zattoo Network, in ACM IMC, 29 [11] K Shami, D Magoni, H Chang, W Wang, and J S, Impacts of Peer Characteristics on P2PTV Networks Scalability, in IEEE INFOCOM, 29 [12] Y Huang, T Z Fu, D-M Chiu, J C Lui, and C Huang, Challenges, design and analysis of a large-scale P2P-VoD system, in ACM SIG- COMM, August 28 [13] L D Acunto, J Pouwelse, and H Sips, A measurement of NAT and firewall characteristics in peer-to-peer systems, in Proc 15-th ASCI Conference, June 29 [14] B Ford, P Srisuresh, and D Kegel, Peer-to-Peer communication across network address translators, ATEC, 25 [15] X WANG and Q DENG, VIP : A P2P communication platform for NAT traversal, in Parallel and distributed processing and applications International symposium No3, Nov 25 [16] S Ren, L Guo, and X Zhang, ASAP: an AS-Aware Peer-Relay Protocol for High Quality VoIP, in IEEE ICDCS, 26 [17] W Kho, S Baset, and H Schulzrinne, Skype relay calls: Measurements and experiments, in IEEE INFOCOM Workshops, Apr 28 [18] R Cuevas, A Cuevas, A Cabellos-Aparicio, L Jakab, and C Guerrero, A collaborative P2P scheme for NAT Traversal Server discovery based on topological information, Comput Netw, August 21 [19] Y Liu and J Pan, The impact of NAT on BitTorrent-like P2P systems, in IEEE P2P, Sept 29 [2] Network Simulator (NS2),