Most of the parameters were selected on the basis of literature survey. The parameters mentioned in the related research work were selected to evaluate the techniques in this study. Besides the parameters, which are specific to tunneling, other parameters, which are mostly used when talked about network layer (like, throughput, round trip time, jitter, and end to end delay) were also used to evaluate the performance
For the purpose of generating traffic, UDP audio streaming traffic was run end to end to calculate the throughput. There were basically four runs of traffic, whose average was calculated and the final graph, shown below, was generated. The graphs (the one in pps and the other one in Kbps) show that ISATAP has got relatively better throughput as compared to the other two protocols.
The packet size remained 1500 bytes. Traffic was run for about five minutes over the test bed setup, which was sniffed using the most widely used packet sniffing tool, called Wireshark. The graph shows that ISATAP performs better in respect of throughput because it performs the simplest possible encapsulation and involves least possible devices. Its throughput remained 40-45 packets per second. 6to4 was the second best, which also performs somewhat similar to ISATAP. Its throughput remained 40 packets per second. As Teredo performs two-level encapsulation, in which it encapsulates every IPv6 packet inside UDP and then that UDP packet, containing IPv6 in its payload, is encapsulated in the IPv4 packet, so its performance is degraded. Its throughput remained 35-38 packets per second. But Teredo is still acceptable because it was meant to traverse IPv6 through NAT boxes, so in such scenarios, where a dual stack end-user is sitting in a private IPv4 network, behind NAT, then Teredo will be the solution for tunneling.
The ultimate, average throughput in Kbps is calculated as.
Throughput = ((No_of_pkts_rcvd / timestampsec ) X 1500 X 8) / 1000 Kbps
Figure 4.2: Teredo-ISATAP-6to4 Throughput in Kbps
Average throughput of 6to4, Teredo, and ISATAP is shown in the following table.
Protocol
Teredo
ISATAP
6to4
Average Throughput (Kbps)
454.67
476.88
462.83
Table 4.1: Average Throughput in Kbps
As the network conditions were more or less stable, because it was a test bed setup, so there is apparently not a huge difference among the protocols. But when deployed over the Internet, this difference will surely increase. There would be more intermediary devices involved in routing the packets and standalone servers would be used to provide prefix to the potential clients. This test-bed setup provides the mean to evaluate these protocols on relative grounds, not on absolute. The average throughput was calculated to make things more comprehensive. As shown in the table 4.1, in relatively stable conditions, ISATAP has the edge of around 20 Kbps on Teredo. For that five minute runs of four traffics, the average shows that ISATAP has got around 14 Kbps better throughput from the other contender 6to4.
2. End to End Delay (E2ED):
It describes delay in milliseconds the traffic incurs.
The formula to calculate end to end delay is.
E2ED = timestampmsg_rcvd - timestampmsg_sent milliseconds
Figure 4.3: Teredo-ISATAP-6to4 End to End Delay in milliseconds
Delay was also calculated on UDP audio streams. It was calculated by subtracting the timestamps of packet received at the receiver end with the timestamp of packet sent by the sender. Again, in terms of delay, ISATAP has got the edge. Its performance is better than the rest. Teredo traffic incurs more delay. This is because Teredo has more overhead due to dual encapsulation (IPv6 encapsulated in UDP-IPv4). This extra encapsulation, which is for a good reason of traversing NATs, adds extra overhead of encapsulation and decapsulation. On the other hand, ISATAP is most recent among its contenders and involve least number of intermediate devices to route traffic.
Average delay for each protocol is shown in the following table.
Protocol
Teredo
ISATAP
6to4
Average Delay (ms)
1.7534
1.2427
1.3090
Table 4.2: Average End to End Delay in milliseconds
Table 4.2 shows that ISATAP incurs least amount of delay in comparison with the other two protocols. When these techniques are deployed over the Internet, there would be lot more devices each packet has to travel through and then this difference would be significant.
3. Jitter:
Jitter, variation in delay, was calculated on the basis of the end to end delay obtained previously. The formula for which is given below.
Jitter = Absolute (delaycurrent_pkt - delayprev_pkt) milliseconds
The first packet won't be having any previous packet, so its jitter is 0.
Figure 4.4: Teredo-ISATAP-6to4 Jitter
Jitter is the only parameter in which ISATAP's performance is inferior from the other two protocols. This is because in ISATAP, tunnel refresh packets, which are meant to refresh the tunnels, are sent more frequently. In our experiments, we found that they are sent after every 13 data packets. When the tunnel is being refreshed and maintained, the data traffic is halted for that interval. In Teredo, tunnel refresh packets are sent after every 21 data packets. This is the reason for Teredo being less jittery. 6to4 again lies in between Teredo and ISATAP. When real time streaming traffic has to be tunneled through IPv4 network, then Teredo appears to be the best option.
Average jitter for each protocol is shown in the following table.
Protocol
Teredo
ISATAP
6to4
Average Jitter (ms)
0.0080
0.0290
0.0225
Table 4.3: Average Jitter in milliseconds
The difference revealed from the above mentioned table 4.3 shows that when these techniques would be deployed over the Internet, ISATAP tunneled traffic would be containing even more jitter, because when there would be lot more devices involved and the network conditions would also be unpredictable, and there would be lot more clients asking for prefix and generating traffic, then those refresh packets would take more time to travel through the network between the client and the ISATAP server. Thence, incurring more jitter and also, affecting the bandwidth as well.
4. Round Trip Time (RTT):
Round trip time is also regarded as one of the key parameter when talking about networks and network layer protocols. RTT is the time taken in total starting from the moment packet left the sending machine till the reply packet received by the sender. To get this, TCP based ICMP-ping traffic was used.
Formula to calculate RTT is given below.
RTT = timestamppkt_rcvd - timestamppkt_sent milliseconds
Figure 4.5: Teredo-ISATAP-6to4 Round Trip Time
The difference between E2ED and RTT is that different traffics were used to calculate each. For E2ED, UDP audio/video streams were used, while for RTT, TCP based ICMP-ping traffic was used because it doesn't contain payload and only a fixed size header was required to be routed, so that exact round trip time is calculated.
Average RTT is shown in the following table.
Protocol
Teredo
ISATAP
6to4
Average RTT (ms)
1.0048
0.5516
0.7193
Table 4.4: Average Round Trip Time in milliseconds
In terms of RTT, ISATAP is again the better choice, because of the very reason of lesser encapsulation overhead.
5. Tunneling Overhead
The amount of overhead caused by creating tunnels, deleting tunnels, refreshing and maintaining tunnels, encapsulation, and decapsulation is known here as tunneling overhead.
Tunneling overhead is measured by subtracting each protocol's RTT with the RTT of untunneled/direct traffic.
Tunneling Overhead = RTTtunneled_traffic - RTTuntunneled_traffic milliseconds
Figure 4.6: Teredo-ISATAP-6to4 Tunneled vs. Untunneled Traffic
The graph above shows the difference between tunneled and untunneled traffic. This untunneled traffic was generated by sniffing traffic sent over the same test bed with all the nodes capable of recognizing IPv6. By this, it gives the clear picture of the difference caused by tunneling.
Figure 4.7: Teredo-ISATAP-6to4 Tunneling Overhead
Tunneling overhead is measured by subtracting RTT of tunneled traffic with the RTT of untunneled traffic, giving the exact amount of overhead caused by overall tunneling. It includes the tunnel setup delay added with processing delay, transmission delay, tunnel refreshing and maintaining, and tunnel teardown.
Average tunnel overhead is shown in the following table.
Protocol
Teredo
ISATAP
6to4
Average Tunneling Overhead (ms)
1.0011
0.5683
0.7124
Table 4.5: Average Tunneling Overhead in milliseconds
7. Tunnel Setup Delay
The total amount of delay incurred in setting up the tunnel to route on the incompatible network. This includes the delay caused by querying the DNS server, connecting to the tunnel server to get the tunnel prefix and in the end tunnel setup confirmation.
Figure 4.8: Teredo-ISATAP-6to4 Tunnel Setup Delay
It takes 2.97 milliseconds to Teredo server in setting up the tunnel for Teredo client. After this initial tunnel setup, the data traffic is routed by the Teredo relays over the incompatible IPv4 network. ISATAP server takes 2.26 milliseconds in doing this. 6to4 lies in between the other two contenders. It takes 2.49 milliseconds for 6to4 infrastructure for initial tunnel setup.
Protocol
Teredo
ISATAP
6to4
Tunnel Setup Delay (ms)
2.97
2.26
2.49
Table 4.6: Average Tunnel Setup Delay in milliseconds
8. Query Delay
The delay incurred in querying the DNS server is referred to as query delay. The significance of this parameter is that each tunneling protocol has got different IP prefix, which the DNS has to keep on updating by the time. Also, the scenario varies regarding the location of the end nodes/hosts. The host may be lying in an IPv6 network. It then has to connect to IPv6-only DNS server to put the query. Host may also be lying in an IPv4 network. In this case, the DNS has to be dual stack to maintain the entries of IPv6 hosts lying in IPv6/IPv4 networks, which are being queried. As the DNS protocol's version, IP prefix and location, all can vary, thus, this parameter was considered vital to evaluate which protocol has got more query delay and which has got relatively lesser. This delay also depends upon the number of hosts querying the DNS server.
Figure 4.9: Teredo-ISATAP-6to4 Query Delay
Teredo client was sitting behind the NAT in this test bed setup (as this is the scenario for which Teredo was specifically designed for). Due to that extra node (NAT), Teredo traffic has to traverse when connecting and querying the DNS server, it takes relatively more time, as compared to the rest. ISATAP and 6to4 have exactly the same scenario. After sniffing four independent runs of traffic, the average query delay obtained for ISATAP and 6to4 is 2.01 milliseconds.
Protocol
Teredo
ISATAP
6to4
Query Delay (ms)
2.47
2.01
2.01
Table 4.7: Average Query Delay in milliseconds
9. Auxiliary Devices Required
Each protocols used in this research work involves some common and some protocol and network specific devices. These devices might not matter in small test bed setups or networks, but they do matter when deployed on a large scale. It all depends upon the type of network (IPv6-only, IPv4-only, dual stack, public network, private network) and the conditions of network. That is why this parameter has been made part of the evaluation.
Figure 4.10: Teredo-ISATAP-6to4 Auxiliary Devices Required
Teredo's RFC states that the Teredo server which gives the prefix to the Teredo client while setting up the tunnel prior to sending data must be a standalone independent device. Teredo relay, which routes the traffic, must be separate from the server. That server would thus be considered as an auxiliary device, as its capabilities cannot be integrated into the Teredo relay according to the RFC. When the network and the number of clients, who want to send tunneled data through ISATAP is small, then there won't be any auxiliary device required. ISATAP's router can do the job of ISATAP server as well, when the functionality is integrated into it. This gives ISATAP an edge over Teredo and 6to4. 6to4 also requires an auxiliary device, called 6to4 relay, to relay traffic meant to be forwarded to the IPv6 network.
Protocol
Teredo
ISATAP
6to4
Auxiliary Devices Required
1
0
1
Device Name
Teredo Server
N/A
6to4 Relay
Table 4.8: No. of Auxiliary Devices Required and device name
