Experiment Results

4.3.1 Handover Latency

The handover latencies are different for each OS. For the following test, handover is triggered manually at 1 sec. The experiment result shows that service disruption is about 1100 ms in Windows Vista, 2000ms in FreeBSD with full scan, 60 ms in FreeBSD without scan and 130ms in Linux.

100

Figure 4.5 Service disruption time in Windows Vista

Figure 4.5 is the result in Windows Vista. From the information provided by sniffer, Windows Vista cost 700 ms in L2 handover and 180 ms in L3 handoff. First, Windows Vista sends disassociation and de-authentication when a mobile host leaves its serving AP.

Second, it turns the wireless NIC to target-AP’s channel based on previous scanning result and scan for that AP. Before it starts to scan, it is idled about 600 ms. If the target AP responded for the probe, Windows Vista stops scanning immediately and starts to connect to the target AP. According to IEEE 802.11, when station connects to an access point, it exchanges authentication message first and then sends association message. We found that Vista does not send association request right after got authentication reply from AP. Actually, it waits about 100 ms.

After L2 connection is completed, it takes about 138 ms to trigger DHCP client to send DHCP request. The RTT of DHCP request and ACK is about 8 ms (including processing time, transmission time and propagation time). If it got DHCP ACK, which means that the client can continue to use the original IP. The Vista sends ARP request for the default router again, and from now on, it can receive packet from the new network. After receiving ARP

reply, it can start to send packet.

Figure 4.6 Service disruption time in FreeBSD without Scan

50

Figure 4.7 Service disruption time in FreeBSD with full Scan

In FreeBSD, there are two modes to switch from one AP to another. If the last scan was taken no earlier than a threshold, the FreeBSD IEEE 802.11 layer will try to direct connection to target AP based on the last scanning result. In this mode, the total service disruption time can be reduced to 60 ms as shown in Figure 4.6. Otherwise, it does a full scan over all available channel and it takes about 1900 ms as show in Figure 4.7. For each channel, the scan takes place for 200 ms on each channel. After finishing scanning the last channel, it starts passive scanning on channel 12 to 14.

Unlink Windows Vista, once a station finished exchanging authentication message, it starts to send association message immediately. After L2 link is connected, the DHCP client on FreeBSD takes 15 to 25 ms to detect link state and start to send DHCP request. The delay on DHCP is about 10 ms and is close to the result from Windows Vista.

Figure 4.8 is the result on Linux. It’s behavior is like Windows Vista but without the idle period. After disconnected from serving AP, it probe for the target AP based on the scan cache and start to connect immediately after the target AP responded the probe. Compare to Windows, the gap between every IEEE 802.11 message is much lower (1-2 ms vs. 100 and 600 ms). In L3 handoff, the DHCP client in the Linux cannot listen to IEEE 802.11 event, the client will not send DHCP request after it associates to the target AP, instead the user has to launch DHCP client manually or execute by other program or script.

50

Figure 4.8 Service disruption time in Linux

There are two common DHCP client in Linux, ISC-DHCP client and udhcpc. The former one is a standard DHCP client and will record the current lease (including IP address, subnet mask, default router etc.), the next time it starts up, it will read the lease file and request for the previous IP first instead of asking for a new one. But this client has a longer startup delay

Vista

0 500 1000 1500 2000 2500

Vista

Figure 4.9 Comparison of handover process in different OS

Vista

Figure 4.10 Comparison of handover process excluding the scanning

about several hundred ms. The later one is a light-weight client, it has lower start up delay but it does not support lease file. Every time it starts, it sends DHCP Discover first and need twice round-trip time between MN and DHCP server. We choose udhcpc as DHCP client in Linux because the delay is less than the other one even if it consumes 2 RTT.

From the experiment result, L2 handover latency is much longer than that in L3 especially when L2 needs to perform scan process. Figure 4.9 is the comparison between L2 & L3 handover latency from different OSs. We can find that full scanning cost the most time during the handover process. Figure 4.10 is the same comparison excluding scanning. Vista costs more time in L2 link connection and its DHCP client takes much more time to detect link change before starting the DHCP process.

The L3 handover latency is related to the RTT of target AP and HA. The experiment environment is in the LAN connected by Ethernet so the latency is low. From the above

experiment, the delay of DHCP request is about 10 ms (about 2 ms of which is link RTT including IEEE 802.11 frame processing time and the remaining is the processing time).

Practically, when an MN is away from home, the RTT from foreign network to home is usually less than 100 ms and is still lower than L2 handover latency.

4.3.2 NAToD Performance

Figure 4.11 is the average number of packets that the router can process per second. The curve forward is the number of packets that the router can process when it operates as router mode. IP routing is based on IP header and is not related to the payload of IP, so its per-formance is the same for different sessions. In our experiment, the perper-formance can reach nearly 300K pps. When the router with NAT is enabled, besides normal routing, it has to lookup conntrack from the hash table and other routine procedure including getting tuple and checking whether the conntrack is valid. This makes the forwarding performance to drop even when the number of session is only 1. The two NAToD curves ‘forward’ and ‘re-verse’ are the performance for outgoing and incoming traffic. Both incoming and outgoing performance are very close for NAT so we just put one result here.

From the result, we can find that outgoing traffic experienced better performance with NAToD when the number of sessions is less than 32768. NAToD needs to compare more fields than NAT when looking up translation table, but it does not have to translate for every packet. That is why the NAToD can process packets faster. When the number of sessions grows, the collision in the hash table also increases. It has to compare every conntrack entry with the same hash value. As a result, NAT performs better than NAToD when number of sessions is more than 32768.

100

Average Packet per Secondx 1000 NAT natod-forward natod-reverse forward

1 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536

Average Packet per Secondx 1000

Number of Sessions

NAT natod-forward

natod-reverse forward

Figure 4.11 PPS vs. number of sessions

Figure 4.12 is the average packet processing time obtained from the reciprocal of the above result. The ‘get tuple’ curve is the time netfilter gets tuple from packet header and other routine job. The ‘conntrack’ curve includes get tuple as well as look up translation table but without NAT. The difference between ‘conntrack’ and ‘get tuple’ is close to the time cost by NAT table (hash table lookup). The other 3 curves NAT, NAToD forward and NAToD reverse are the time cost by traditional NAT, NAToD with outgoing traffic and NAToD with incoming traffic, respectively.

The reciprocal of pps is the processing time for a single packet, but we cannot compare these numbers and calculate overhead based on dividing NAToD’s processing time by NAT.

The processing time includes the time cost in driver, MAC layer, IP layer and NAT. We calculate the relative time by the difference between the NAT/NAToD curve with the forward curve.

3

16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536

Average Processing Time (μS)

Figure 4.12 Packet processing time vs. number of sessions

For incoming traffic, NAToD scheme does not require looking up routing and ARP table, it gets better performance than NAT even when the number of session reaches 65536. When number of sessions is less than 128, it is faster than normal routing with conntrack. That is, the time save in routing and ARP table lookup is more than the time consumed by NAToD table.

Figure 4.13 is also the average packet processing time with different network adapters (setup 2). We can find that although packet processing time is greater than the previous result, the difference between NAT and forwarding is close to the previous result. The processing time in NAT and NAToD layer grows when the number of sessions gets larger. It shows that we should measure the relative processing time instead of simply measuring the pps.

Table 4.1 is the comparison of time consumption between NAT and NAToD. When the number of sessions is less than 4096, NAToD spends about 90% processing time of NAT.

12

128 256 512 1024 2048 4096 8192 16384 32768 65536

Average Processing Time(μS)

Figure 4.13 Packet processing time vs. number of session on configuration 2

NAToD spends more time when the number of sessions is more than 32768 but the overhead is still less than 10% which is acceptable.

From the above result, when the router is equipped with better NIC, it can process more packets. With poor NIC, it takes much more CPU time on interrupt service routine and cause the pps drop tremendously. Comparing the packet processing capacity between normal forwarding and NAT, with poor NIC, the number of packet drops about 24%, and packet drops 60% when using a high performance NIC. Although the later one drops more, but the number of packets it can process is almost double of the former one. The overhead of NAT (the difference between forward curve and NAT curve) is much more than the difference between NAT and NAToD.

Table 4.1 Packet processing time and overhead of NAT and NAToD

No. of sessions ≤ 128 256 512 1024 2048 4096 8192 16384 32768 65536

Setup 1

NAT - 2.139 2.527 2.696 2.785 2.844 2.957 3.255 3.852 5.083 NAToD - 1.960 2.313 2.434 2.495 2.504 2.707 3.117 3.788 5.394 overhead -10 -8.38 -8.44 -9.72 -10.40 -11.97 -8.46 -4.25 -1.67 6.13

Setup 2

NAT - 1.372 1.760 1.870 1.895 1.921 2.078 2.355 2.801 3.530 NAToD - 1.184 1.585 1.737 1.755 1.852 1.966 2.298 2.867 3.734 overhead -12.95 -13.69 -9.95 -7.08 -7.42 -3.60 -5.38 -2.41 2.35 5.77

Unit: µSec.

Chapter 5