Colloquium 2013

WiTracer-A Novel Solution to Improve TCP Performance over Wireless Networks

Authors: Chaoxin Hu, Xinyu Yang, Manli Fan, Peng Zhao

Xian Jiaotong University, China

Publishing year: - 2013 Student Details:Name:- Siddhant Kishore Registration No: - 2011CA72 MCA 5th Semester

Contents
Sl No.
1 2 3 4 5 6 Introduction Objective of the Application Architecture and Methodology Real Case Test Data with Performance Evaluation Conclusion References

Topic

Page No.
3 4 4 8 10 10

2|Page

Introduction
TCP (Transmission Control Protocol) is the most popular and most reliable transport layer protocol used in the current Internet from past decades. As we know, TCP can provide end-toend, in-order and loss-free packet delivery. With the rapid growth of the number of 3G/Wifi users, it becomes even more important to improve TCP performance over wireless network, due to the fact that TCP is still the most widely used protocol in wireless communication. However, there exist several problems, which TCP Reno-based variants will encounter if they are implemented in wireless scenario. Firstly, the end-to-end performance is constantly degraded if TCP congestion control algorithm is unnecessary invoked: many TCP variants drop their sending rates by reducing the Congestion Window (CW) of the sender if sender receives 3 Duplicate-Acknowledgement (DupACK) packets. This is because TCP assumes each of the DupACK to originate from Congestion, whereas the real causes of loss may be the handover or mobility factors. Secondly, variation of wireless channel further increases the burden of wireless TCP, and leads to the occurrence of unexpected TCP behaviors, e.g. Spurious, unexpected ACKs and Retransmission Time-out (RTO). Thirdly, original TCP loss-recovery schemes have several inherited weakness which is even exaggerated in wireless network. As a result, great throughput degradation is observed. In this report, we analyse WiTracer, a novel solution to improve TCP performance over wireless network. Our objective is to address the above mentioned issues thus to preserve a stable and desirable throughput for end-to-end wireless TCP. WiTracer consists of two main modules, the Congestion Identifier module and the Opportunistic Recovery module. Congestion Identifier seeks to combine both Round-Trip-Time (RTT) and Loss information to decouple packet loss from congestion. Secondly, Opportunistic Recovery module proceeds local recovery using opportunistic single DupACK, and it can also react to the spurious DATA and ACK loss, which mitigates wireless-incurred RTO.

3|Page

Objective of the Application

In this report, we present WiTracer, a novel solution to improve TCP performance over wireless network. Our objective is to address the aforementioned issues thus to preserve a stable and desirable throughput for end-to-end wireless TCP. WiTracer consists of two main modules, the Congestion Identifier module and the Opportunistic Recovery module. Congestion Identifier seeks to combine both Round-Trip-Time (RTT) and Loss information to decouple packet loss from congestion. Secondly, Opportunistic Recovery module proceeds local recovery using opportunistic single DupACK, and it can also react to the spurious DATA and ACK loss, which mitigates wireless-incurred RTO.

Architecture and methodology

WiTracer Design :Our goal is to mitigate all the aforementioned drawbacks for wireless TCP. WiTracer intends to fill this gap; it makes TCP more adaptable to wireless specifications, and also less dependable on using inefficient inherent TCP congestion control, or RTO, to recover losses. To make WiTracer stronger, we suggest that our solutions are regulated by the following principles: 1) Compatibility. Designs should never break down original TCP semantics, avoid adding new header fields,and should support all mainstream TCP variants. 2) Stability. Any radical change to existing TCP congestion control scheme should be avoided to preserve network stability and TCP friendliness. 3) Scalability. The designed modules should be kept coupling-free, cost-minimal and transparent to TCP. The architecture of WiTracer is shown in Figure given below. It contains two components: Congestion Identifier and Opportunistic Recovery. WiTracer needs to be inserted on both TCP sender and receiver sides as the middleware for incoming and outgoing TCP flows in order to meet full functionalities. At receiver side the out-of-order and Spurious DATA issues are solved, while at the sender side congestion identification and the rest of the drawback issues are tackled.

Figure 1 : Architecture of WiTracer

4|Page

TCP Background
TCP is designed to provide ordered and error-free packet transmission. Each sender can send new DATA packets, with quantity equal to the current Congestion Window (CW) size, upon previous ordered DATA being acknowledged (ACK) by the receiver. On the contrary, when the receiver receives any out-of-order or lost packets, it will send DupACK packet whose ACK number is smaller than expected ACK number. Hereafter, when sender receives more than 3 DupACKs, it will recognize this as a sign of network congestion; then, the congestion control is begun: CW size is reduced, throttling DATA rate to avoid congestion. However in wireless networks, the majority of packet loss are originated from random wireless link transmission error because of various causes as fading, attenuation, etc. Moreover, if losses appear in conjunction with link layer recovery mechanisms, transmission delays will become fluctuated and unbounded which further results in frequent out-of-order packet delivery and RTO. In reality, loss and out-of-order are hardly correlated with congestion, which also means that congestion is rather a rare event to be found in TCP, and should be treated differently with packet loss. Unfortunately, Reno-based TCP cannot differentiate packet loss and out-of-order from congestion - it just blindly reduces CW but such effort is in vain. Then, designing an alternate approach to reduce the unnecessary invocations of TCP congestion control is important. Despite these problems, Reno-based TCP also has following drawbacks which incur frequent throughput degradation.

Figure 2
The above figure shows drawbacks in wireless TCP. From left to right we show examples of Hungry RTO, RTX-DATA Loss, and two possible causes of Spurious DATA. The value represents SEQ number of DATA (Sender), and ACK number of ACK (Receiver). It is clear that these drawbacks either occur unexpected RTO or induce bandwidth wastage (marked in red). Note that Variation and ACK-loss may both cause Spurious DATA, and should be treated differently

WiTracer Operation Principle

WiTracer is made up of two modules. These two modules should be employed in between the TCP sender and TCP receiver at both the ends. The two modules are:

5|Page

Congestion Identifier
Neither RTT nor packet loss information is enough to recognize congestion individually, as variations in RTT and Spurious packets induce inaccuracy. Therefore WiTracer combines both packet loss and RTT information to identify congestion, which works as follows: 1. To begin with, the identifier will maintain a record entry for each flow, < ACK, Loss, RTT >, referring to the received inbound ACK packets. Upon receiving any ordered ACK, the identifier will add an entry to this record, setting the ACK field to be equal to the ACK number of the packet and Loss field to be 0. This also includes SYN-ACK which comes from TCP 3-way handshake. 2. On the other hand, when identifier receives a DupACK, it will add a corresponding entry with Loss = 1. It is worth noting that if SYN, SYN-ACK or first ACK is retransmitted, the Loss field of SYN-ACK will be set as 1. 3. Then, WiTracer instantly employs a window whose size is equal to the current CW size, checking for this DupACK together with its previous ACK entries. Within this window, the identifier detects whether there exists at least lossThresh packets with Loss = 1, and also, whether their averaged RTT is greater equal to RTTThresh. 4. If both requirements are fulfilled, this DupACK is recognized as an indicator of congestion, and will be forwarded to further trigger congestion control with following 2 same DupACKs. Otherwise, it will be identified as the normal wireless incurred packet loss, and be delivered to the Opportunistic Recovery module to invoke local retransmission. Such identification is specifically validated in DropTail-based queuing networks. Specifically, lossThresh and RTTThresh is given by: lossThresh = max{2 , M CW} RTTThresh = RTTmean + 2RTTvar

(1)

where RTTmean and RTTvar are obtained using Equation 2 below. For lossThresh, Equation (1) uses a parameter, M, to denote the threshold of the proportion of lost packets in a CW (We set M = 0:25 in practice). For RTTThresh, it measures whether the lost packets deviates too much from the previous RTT values. Upon every received ACK packet i, the RTTi can be obtained by subtracting the timestamp when corresponding DATA packet is sent, from the timestamp when identifier receives its ACK. Then, RTTi is further smoothed using the exponential weighted moving average. In Equation (2) underneath, a general form of Low-pass filter of RTT is presented, which is originated from TCP Timestamp Option. The default value of is set 0.125 in the experiment. RTTmean = (1 -) . RTTmean + .RTTi RTTvar = (1 -2) . RTTvar + .| RTTi RTTmean |

(2)

6|Page

Opportunistic Recovery
In WiTracer, Opportunistic Recovery is based on a simple intuition: instead of using 3 DupACKs to initiate retransmission, we find that, actually only a single DupACK (opportunistic) is enough to invoke retransmission for loss recovery. This is because that 3 DupACKs is used as a stability-oriented threshold to filter out-of-order instances within the range of two packets. However it also makes it less efficient to invoke loss recovery especially when congestion window is small. Then if both out-of-order and Spurious DupACK can be reduced at the receiver to utmost, using single DupACK is already enough for efficient local recovery, and can mitigate drawbacks mentioned in previous Topic. Note that our Opportunistic Recovery module does not change the original TCP congestion control.

Figure 3
Figure 3 shows WiTracer mitigation of drawbacks. Green term shows the side where WiTracer functions. Dash-dot arrows represent DATA packets generated by Sender-ware local recovery, and solid arrows are the DATA packets sent by the Sender. For Hungry RTO a), loss is identified at the first DupACK and henceforth is opportunistically replied, with following DupACKs dropped. For RTX-DATA Loss b), Sender-ware resends DATA 1 after the interval is expired. In Spurious DATA case c), we assume the original DATA packet 1 comes after local recovery initiated, and before recovered Spurious DATA arrives at Receiver-ware. Therefore, Original DATA is acknowledged, but Spurious DATA is dropped since it is within FilThresh. In d), the real recovered Spurious DATA is correctly acknowledged since it comes after FilThresh in most cases. It is worth noting that if DATA 4 comes before Spurious DATA 3,then Spurious DATA 3 is simply dropped by Receiver-ware.

Real Case Test Data Available and Performance Evaluation

Simulation Preliminaries
We implemented WiTracer using Network Simulator-2, together with the simulation setup. The network is composed by a wired link connecting the TCP source to a base station, which has a wireless LAN interface to establish a wireless link to a TCP receiver. We generate FTP traffic from the TCP source to the receiver. Each data trace is kept running for 100 seconds, and is averaged from 50 trials, in order to eliminate the randomness of simulation results.

7|Page

Simulation Results
We are particularly interested in the following two metrics: the end-to-end throughput and perpacket RTT with respect to different values of wireless link packet loss rates and delay variations. The throughput is calculated by accumulating the size of the ACKed DATA packets, while the RTT is the elapsed time for every DATA packet, between the moment it is sent by the receiver and it is ACKed. Figure 4 (a) shows the end-to-end throughput when given wireless channel is experiencing varying packet loss, ranging from 0.01% to 5%, and delay variance of 10ms. It can be seen that for each benchmark results, the throughput degrades with the increasing of packet loss probability. However, WiTracer observes an average throughput increase of 30%, which is invariant to different packet loss conditions. Packet Controller (PktCtrl) provides a steady improvement around 10% of the mean throughput. For TCP Casablanca,its throughput is around 23% when the loss probability is rather low, whereas the value drops down to 18% when loss is high. TCP-NCE has satisfactory improvement (35% in low loss case), however its performance degrades drastically in high packet loss case (with only 13%). A detailed research shows that higher packet loss forbids Senders CW from growing up, as RTOs enumerates consequently around the beginning of congestion avoidance phase of TCP, henceforth the CW will never have chances to enlarge. This is mitigated by WiTracer as Hungry RTO, respectively. It is also confirmed that WiTracer and PktCtrl have lower fluctuation of throughput, since they are able to filter out Spurious packets. Figure 4 (b) demonstrates the throughput under varying delay variance of wireless channel, from 10ms to 50ms (for dual-end it becomes 20-100ms). The packet loss is fixed at 0.1% in this scenario. We observe that despite all approaches exhibit a considerable descending trend in throughput, WiTracer still provides about 20% - 25% of throughput improvement to baseline TCP SACK Reno result. For other approaches, the performance in high variation cases becomes excessively poor (sometimes even drops beneath original TCP SACK Reno), due to the fact that the occurrence of outof-order and Spurious packets is much more common than congestion, which is captured and mitigated by WiTracer. Figure 4 (c) & (d) represents the per-packet RTT in varying packet loss and delay variation cases. It is shown that the RTT does not deviate too much with the sum of the two-way delay when the packet loss is low, for every approach. However, the extra time elapsed on link-layer retransmission with other mechanisms gradually increases, which enlarge the observed RTT, and henceforth the throughput is also degraded. Moreover, the increased packet loss and variations bring in more out-of-order with spurious packets, which leaves little chance for Sender CW to increase. Among all the approaches, WiTracer still offers the smallest RTT value, even in high packet loss and variance cases

8|Page

Figure 4 (a)

Figure 4 (b)

Figure 4 (c)

Figure 4 (d)

9|Page

Conclusion
The several major causes and occasions that result in TCP performance degradation were identified. Therefore, a novel solution to improve TCP performance over wireless network, WiTracer, was proposed. It is composed by Congestion Identifier and Opportunistic Recovery. Congestion Identifier checks for each DupACK packet and implement local recovery, while Opportunistic Recovery provides a faster recovery rate of DupACK and mitigates several TCP drawbacks: Hungry RTO, RTX-DATA Loss, and Spurious DATA. Simulation results show that WiTracer outperforms existing benchmarks. WiTracer can be easily launched on mobile devices (Android/iOS) for various applications.

References
[1] K. Fall and S. Floyd, Simulation-based comparisons of Tahoe, SACK TCP, ACM SIGCOMM CCR, vol. 26, pages 5-21, Jul. 2011. [2] K. W. Lien, J. S. Reeve, and Y. J. Lee, Improving TCP performance over wireless networks, in Proc. Int. Symp. On Telecommunications 08, pages 424-428, Aug. 2010 [3] S. Biaz and N. H. Vaidya, De-Randomizing congestion losses to improve TCP performance over wired-wireless networks, IEEE/ACM Trans. On Networking, vol. 13, no. 3, pages 596-608, Jun. 2009. Class Instruction Materials, Dr. Mayank Pandey, Mobile communications, MNNIT, 2013. The Network Simulator: ns-2. http://www.isi.edu/nsnam/ns

10 | P a g e