Chapter 5 NBA TCP Traversal Scheme
5.5 Step 3 of NBA – Connectivity Check
An initiator of two UAs then initiates connectivity check with the notify methods which is selection by NBA Server based on information of their NATs.
Chapter 6
System Implementation
This chapter describes system implementations of NBA scheme. Section 6.1 presents the system overview. Section 6.2 shows our current implementation. Section 6.3 discusses ways to determine the most appropriate traversal method in different con-siderations.
Figure 6-1 System modules of NBA
6.1 System Overview
Figure 6-1 illustrates the system topology and modules of NBA scheme. NBA topology which is similar to traditional NAT traversal topologies consists of two UAs behind NATs and a third-party server named NBA Server. The NBA Server located on the internet provides three modules that are NAT Type Tests Module, Traversal Method Selection Module and Direct Connection Module. As for UA, it has two modules that are Information Collection Module and Connectivity Check Module.
6.2 NBA Implementation
In NBA, all implementations are based on Linux and use C language. As shown in Figure 6-1, NBA provides the following functional components:
NBA UA
1. Information Collection Module: NBA Server provides seven type tests such as Mapping test, ESi test, Si test, SoSi test, SoRiSi test, SoUiSi test and SoTiSi test, and each test was described in detail in chapter 5. Information Collection Module provides an interface for NBA UA to perform these NAT type tests to collect knowledge of its NAT. This module is integrated form the client side of STUNT. STUNT was implemented by Cornel University at 2005 and it ex-tends STUN to include TCP functionality [22]. STUNT is a lightweight pro-tocol that allows UAs running behind a NAT to determine external IP and port-mapping properties, packet filtering rules and various timeout associated with TCP connections through the NAT.
2. Connectivity Check Module: Connectivity Check Module implemented three kinds of TCP NAT traversal methods that are SNT, SLT and ESi. This module can assist NBA UAs to perform connection check with current traversal
me-brary and can assist two hosts behind NATs to establish a direct TCP connec-tion via traversal methods [23].
NBA Server
1. NAT Type Tests Module: NAT Type Tests Module which corresponds to In-formation Collection Module in NBA UA provides seven NAT type tests, and it assists UAs to collect NAT information. This module is integrated form the server side of STUNT. Similarly, it has the functionality for UAs to determine its NAT‟s external IP and port-mapping properties, and it can generate several special packet sequences to test TCP state tracking of NAT by using row socket.
2. Traversal Method Selection: Traversal Method Selection implements a se-lection algorithm which is introduced in chapter 5 to select the most appropri-ate traversal method according to information of two communicating NATs.
In NBA, this method selection is implemented in NBA Server. However, there are different approaches to implement this method selection and put it in dif-ferent location, and we will discuss in detail in the next section.
3. Direct Connection Module: Direct Connection Attempting Module provides the functionalities of connectivity check for UAs, and it is integrated form the server side of XSTUNT. This module which corresponds to Connectivity Check Module in NBA UA implements the three TCP NAT traversal methods, too. It assists UAs to perform connectivity check.
6.2.1 Interaction of Modules
In this section, we describe the interactions of modules in NBA. Figure 6-2 shows the module interaction of Step 1 in NBA. UA uses Information Collection Module to
interact with NAT Type Tests Module in NBA Server for collecting NAT information which are mapping rule, filtering rule and TCP state tracking.
Figure 6-2 Module interaction flow of Step 1
Figure 6-3 shows the module interaction of Step 2 in NBA. UA interacts with Traversal Method Selection in NBA Server by submitting its NAT information, and Traversal Method Selection uses behavior information of the two NATs to determine the most appropriate traversal method, and then NBA Server informs UAs the selected tra-versal method.
Figure 6-3 Module interaction flow of Step 2
Figure 6-4 shows the module interaction of Step 3 in NBA. UAs use Connectivity
ing connectivity check with the selected traversal method.
Figure 6-4 Module interaction flow of Step 3
6.3 Discuss Ways to Implement NBA Scheme
We could implement a Signal Server in NBA to maintain all UA‟s information including ID and NAT type information. Once a UA wants to establish a direct connec-tion with another UA via connectivity check, it can send a request message to NBA Server. Then NBA Sever fetch the two UA‟s information from Signal Server.
Chapter 7 Experiment
Figure 7-1 Experiment environment
NBA scheme developed several NAT type tests and the selection algorithm of se-lecting the most appropriate traversal method. This scheme also integrated three kinds of TCP NAT Traversal methods on Linux. In this chapter, we present our experiment environment and describe the process of our experiments and then analyze results of experiments. We use two groups of NATs to construct a fully mesh architecture as shown in Figure 7-1. In our environment, we have a NBA Server and two peers, caller and callee, and execute NBA scheme under two group of NAT which were bought by us at 2008 and 2010. Table 7-1 shows brands of the 36 NATs.
Table 7-1 Brands of NATs
In our experiment, we analyze performances of NBA under various NAT combi-nations to establish a direct TCP connection through NAT connectivity check. As we described in chapter 5, there are three steps in NBA. In the following sections, we present the results of these three steps in NBA respectively, and we compare NBA scheme with the following two schemes:
Sequential Connectivity Check with Initiator Changes (IC):
This scheme tries each traversal method one-by-one and change initia-tor to tray each method in opposite direction, so the executive order of traver-sal methods about connectivity check in this scheme is SNT SNT-IC SLT SLT-IC ESi ESi-IC
Parallel Connectivity Check (PCC)
This scheme tries all traversal methods at the same time that are SNT &
SNT-IC & SLT & SLT-IC & ESi & ESi-IC
We compare NBA with the two schemes in three metrics that are 1. Direct Connection Rate (DCR)
2. Connectivity Check Time 3. System Resource Utilizations
7.2 Result of Step 1 in NBA
Step 1 of NBA is for UA to collect its NAT information about mapping rule, fil-tering rule and TCP state tracking. After UA perform NAT type tests, it has a compre-hensively knowledge of it NAT. For the purpose of convenience, NATs are marked by us with symbols that mean NATs has corresponding types. The naming rule is listed on Table 7-2, Table 7-3 and Table 7-4. In Table 7-2, if a NAT‟s test results of Mapping test is randomly dependent, we mark the NAT a notation „I‟. That means the NAT is im-possible to be traversed. Next, there are three kinds of test results about Si test, and each result has a unique mark such as „D‟, „R‟ or „U‟ as shown in Table 7-3. A NAT only has one kind of result, because it chooses one kind of response to respond unsolicited in-bound packets. Then, if a NAT allows ESi test, we mark the NAT a notation „E‟. Finally, SoSi, SoRiSi, SoTiSi and SoUiSi test are four type tests about TCP state tracking detec-tion, if a NAT allows some kinds of these tests, we mark a corresponding symbol that are „d‟, „r‟, „t‟ and „u‟ as shown in Table 7-4. For example, if a NAT drops unsolicited packets, and it allows “SoSi” and “SoTiSi” tests but does not allow “SoRiSi” test, we mark the NAT as “D-dt”.
Table 7-2 Naming rule of mapping detection Mapping Detection
Randomly dependent
Mapping I (Impossible to be traversed)
Table 7-3 Naming rule of filtering detection Filtering Detection
Drop RST Host Unreachable
Si D R U
Yes
ESi E
Table 7-4 Naming rule of TCP state tracking detection Filtering Detection
SoSi SoRiSi SoTiSi SoUiSi
Mark d r t U
We can then mark NATs in group A and group B according to this naming rule.
Table 7-5 presents marking result of NATs in group A while Table 7-6 shows NATs in group B.
Table 7-5 Classify of NATs in group A Test Results
A14, A16,
Table 7-6 Classify of NATs in group B Test Results
7.3 Result of Step 2 in NBA
Step 2 of NBA is for NBA Server to determine the most appropriate traversal me-thod base on information of two communicating NATs. Table 7-7 shows the results of Step 2 in NBA about traversal method chosen by NBA Server to each connection com-bination of NATs in group A. Behaviors of NATs in the same class are the same, so NBA Server chooses the same traversal method to connection combinations in a kind of class combination. Since we consider two peers are under different NATs only, there have no combination of NATs in some cases. In Table 7-7, numerals mean three kinds of three TCP traversal methods implemented in NBA, and notation „R‟ means the NATs of combinations cannot be traversed to establish a direct connection and must use relay method. Moreover, notation “N/A” means the block has no connection combination, and notation “IC” means callee must be the initiator of connectivity check. Similarly, Table 7-8 presents selected methods of connection combinations of NATs in group B.
Table 7-7 Traversal method selected by NBA to group A
Responsor
Table 7-8 Traversal method selected by NBA to group B
Responsor
Class ED-drt D-drt D-dt D-^ R-^
In it ia to r
ED-drt N/A 3 3 3 3 D-drt 3, IC 1 1 1 1 D-dt 3, IC 1 1 1 2 D-^ 3, IC 1, IC 1, IC R R R-^ 3, IC 1, IC 2, IC R R
7.4 Comparison of Direct Connection Rate in Different Schemes
In this section, we compare direct connection rate of NBA scheme with SCC and PCC schemes.
7.4.1 Result of Step 3 in NBA
Step 3 of NBA is for UAs to perform TCP NAT traversal via the method which is chosen by NBA Server in Step 2. Table 7-9 and Table 7-10 present the connectivity check results of group A and group B after performing Step 3 in NBA. We put an aste-risk () to a block when each connection combination can establish a direct TCP con-nection in the block. The DCR is 56.84% in group A and 54.17% in group B by using NBA scheme.
Table 7-9 Direct connection of group A made by NBA
Table 7-10 Direct connection of group B made by NBA Responsor
In summary, according to experimental data of section 7.3 and section 7.4.1, we could conclude that it does not have any error selection existing in NBA selection algo-rithm. Therefore, we could claim that traversal method chosen from NBA Server can succeed in traversal target NATs exactly. NBA has no miscarriage of justice about tra-versal methods while connectivity checks.
: Direct Connection N/A: Non-Existent
7.4.2 DCR of Other Traversal Scheme
SCC with change role or PCC 1. Group A
Table 7-11 Direct connection of group A made by SCC or PCC Responsor
Table 7-12 Direct connection of group B made by SCC or PCC Responsor
7.5 Comparison of System Resource Utilization in Different Schemes
The bottom layer of implementations for the three kinds of TCP NAT traversal methods are the same in SCR, PCC and NBA scheme. All schemes use the prototypes implemented by D-Link NCTU Joint Research Center (DNJRC). Therefore, the
schemes have the same procedures and waiting time in each traversal method.
7.5.1 Connectivity Check Time
In this section, we make a comparison of the total connectivity check time in SCC, PCC and NBA scheme. Table 7-12 presents average connectivity check time of different traversal methods; we experiment ten times of each data. Due to each traversal method only exchange a few message to traverse NATs, it takes a very short time which connec-tivity checks. However, when connecconnec-tivity check fails, we must spend several seconds to wait for results. Besides, connectivity check time of Relay is set to be zero because our experiment focuses on direct connection. We assume it is the time that UAs start to establish relay connection.
Table 7-12 connectivity check time
SNT SLT ESi Relay
Success 1.1602 s 0.1605 s 0.0917 s 0 s
Failure 9.2514 s 8.1507 s 8.0739 s ---
Table 7-13 Traversal time of each scheme
Initiator SCC PCC with Relay NBA
Table 7-13 shows traversal time of each scheme. Because SCC applies each tra-versal method one-by-one, it has to accumulate failure time of performed tratra-versal me-thods. For example, if two UAs use SCC scheme to perform connectivity check, finally callee initiates this check and use ESi traversal method to successfully traverse NATs.
This procedure has to accumulate failure time of SNT, SNT-IC, SLT, SLT-IC and ESi.
And also add successful time of ESi-IC. It is a long period of time.
The concept of PCC is using all traversal methods at the same time, but there are two approaches to apply Relay method. Someone applies Relay in parallel with other traversal methods; while the other applies it after fail in direct connectivity check.
Therefore, while applying Relay in after fail in direct connectivity check, the connectiv-ity check time is the longest one of failure time between traversal methods except Relay.
NBA could eliminate unnecessary connectivity checks, so it does not have to take the time of fail in applying traversal methods.
7.5.2 Resource Utilizations
Table 7-14 shows numbers of message exchanges about each traversal method.
Table 7-14 Numbers of message exchanges of each traversal method
SNT SLT ESi Relay
Numbers 6 6 3 6
Table 7-15 Numbers of message exchanges of each scheme
Initiator SCC PCC with Relay NBA
Table 7-15 shows numbers of message exchanges about schemes. Because PCC performs all traversal methods in the same time, it must accumulate all numbers of message exchanges in traversal methods. Therefore, it should use a large of system re-sources within connectivity check procedure.
In summary, according to experimental results of this chapter, NBA has shorter connectivity check delay than SCC and less resource usages or simpler state mainten-ance than PCC. Besides, NBA always knows whether we can use the existing traversal methods to traverse successfully with specific combination of NATs. But SCC has no idea about traversal methods to NAT combinations. Therefore, PCC sometimes could have higher DCR than SCC.
Chapter 8
Conclusions and Future Works
In this thesis, we have demonstrated that NBA is a powerful TCP traversal scheme. It utilizes NAT information comprehensively to select the most appropriate traversal method to traverse NATs. NBA has a priori knowledge on connectivity of each combination of NAT types. Moreover, NBA could eliminate unnecessary connectivity checks, because it knows what combinations of NAT types are traversable. Therefore, we need not perform NAT traversal when direct connection is impossible. By perform-ing NBA, connectivity check of TCP NAT traversal will be more efficient with shorter check delay, fewer message exchanged, possible higher DCR and less resource usages or simpler state maintenance compared to other schemes.
In NBA, many NAT type examinations are declared to understand a comprehen-sive set of NAT characteristics as they pertain to TCP, and we develop an algorithm of traversal method determination. We have shown that this algorithm has good judgment in selecting traversal method.
In the future works, there are still many research issues of the proposed scheme.
For example, we only implemented three kinds of practical TCP NAT traversal methods in this thesis. Maybe we can implement other current TCP NAT traversal methods such as STUNT #1 and NATBlaster. The direct connection rate will thus increase because of including new methods. In the other hand, perhaps we can develop new TCP traversal methods based on our comprehensively knowledge about TCP NAT behaviors.
NBA uses NAT information to select the most appropriate traversal method, but everyone has his own definitions of appropriateness. Maybe we could give an objective
ferent selection results. Therefore, the procedure of method selection in NBA will be more general and more universal. Besides, we would also try to make our scheme more robust for fault tolerance and shorter time delay.
Bibliography
[1] K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” IETF RFC 1631, May 1994.
[2] B. Ford, P. Srisuresh and D. Kegel, “Peer-to-Peer Communication Across Network Address Translators,” in USENIX Annual Technical Conference, pp. 179-192, April 2005.
[3] D. kegel, “NAT and Peer-to-peer Network,” http://www.kegel.com, July 1999.
[4] J. Rosenberg, J. Weinberger, C. Huitema and R. Mahy, “STUN – Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs),”
IETF RFC 3489, March 2003.
[5] J. Rosenberg, R. Mahy and P. Matthews, “Traversal Using Relay around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” IETF RFC 5766, April 2010.
[6] J. Rosenberg, “Interactive Connectivity Establishment (ICE): A Protocol for Net-work Address Translator (NAT) Traversal for Offer/Answer Protocols,” IETF RFC 5245, April 2010.
[7] Jeffrey L. Eppinger, “TCP Connections for P2P Apps: A Software Approach to Solving the NAT Problem,” Technical Report CMU-ISRI-05-104, Carnegie Mellon University, January 2005.
[8] F. Audet and C. Jennings, “Network Address Translation (NAT) Behavioral Re-quirements for Unicast UDP,” IETF RFC 4787, January 2007.
[9] J. Rosenberg, R. Mahy, P. Matthews and D. Wing, “Session Traversal Utilities for NAT (STUN),” IETF RFC 5389, October 2008.
[10] D.Clark, L. Chapin and V. Cerf, “Towards the Future Internet Architecture,” IETF
RFC 1287, December 1991.
[11] Z. Wang and J. Crowcroft, “A Two-Tier Address Structure for the Internet: A solu-tion to the problem of Address Space Exhaussolu-tion,” IETF RFC 1335, May 1992.
[12] Y. Rekhter, B. Moskowitz and D. Karrenberg, “Address Allocation for Private In-ternets,” IETF RFC 1918, February 1996.
[13] S. Guha, K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh, “NAT Behavioral Re-quirements for TCP,” IETF RFC 5382, October 2008.
[14] S. Guha, Yutaka Takeday and P.Francis, “NUTSS: A SIP-based approach to UDP and TCP network connectivity,” in ACM SIGCOMM Asia Workshops, August 2004.
[15] A. Biggadike, D. Ferullo, G. Wilson and A. Perrig, “NATBLASTER: Establishing TCP connections between hosts behind NATs,” in ACM SIGCOMM Asia Work-shop, April 2005.
[16] S. Guha and P. Frances, “Characterization and Measurement of TCP Traversal through NATs and Firewalls,” in 5th ACM SIGCOMM conference on Internet Measurement, pp. 18-18, October 2005.
[17] S. Guha, K. Biswas, B. Ford, S. Sivakumar and P. Srisuresh, “NAT Behavioral Re-quirements for TCP,” IETF RFC 5382, October 2008.
[18] Cheng-Yuan Ho, Fu-Yu Wang and Chien-Chao Tseng, “To Call or to Be Called under NATs is Sensitive for Solving Direct Connection Problem,” Submitted to IEEE Communications Letters, 2010.
[19] P. Srisuresh, B. Ford and D. Kegel, “State of Peer-to-Peer (P2P) Communication across Network Address Translators,” IETF RFC 5128, March 2008.
[20] R. Roverso, S. El-Ansary and S. Haridi, “NATCracker: NAT Combinations Mat-ter,” in 18th International Conference on Computer Communications and Network 2009, pp. 1-7, August 2009.
[21] Zhou Hu, “NAT Traversal Techniques and Peer-to-Peer Applications,” HUT T-110.551 Seminar on Internetworking, 2005.
[22] STUNT, http://nutss.gforge.cis.cornell.edu/stunt.php
[23] XSTUNT, http://www.cis.nctu.edu.tw/~gis87577/xDreaming/XSTUNT/index.html [24] R. Denis-Courmont, “Test Vectors for Session Traversal Utilities for NAT
(STUN),” IETF RFC 5769, April 2010.
[25] D. MacDonald and B. Lowekamp, “NAT Behavior Discovery Using Session Tra-versal Utilities for NAT (STUN),” IETF RFC 5780, May 2010.