You are on page 1of 10

Colloquium 2013

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

Authors: Chaoxin Hu, Xinyu Yang, Manli Fan, Peng Zhao
Xi’an 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 .

g. As a result. However.Introduction TCP (Transmission Control Protocol) is the most popular and most reliable transport layer protocol used in the current Internet from past decades. Opportunistic Recovery module proceeds local recovery using opportunistic single DupACK. great throughput degradation is observed. and leads to the occurrence of unexpected TCP behaviors. there exist several problems. it becomes even more important to improve TCP performance over wireless network. e. whereas the real causes of loss may be the handover or mobility factors. which mitigates wireless-incurred RTO. unexpected ACKs and Retransmission Time-out (RTO). Firstly. a novel solution to improve TCP performance over wireless network. Thirdly. the Congestion Identifier module and the Opportunistic Recovery module. TCP can provide end-toend. As we know. 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. due to the fact that TCP is still the most widely used protocol in wireless communication. 3|Page . In this report. With the rapid growth of the number of 3G/Wifi users. This is because TCP assumes each of the DupACK to originate from Congestion. we analyse WiTracer. Secondly. and it can also react to the spurious DATA and ACK loss. which TCP Reno-based variants will encounter if they are implemented in wireless scenario. 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. Congestion Identifier seeks to combine both Round-Trip-Time (RTT) and Loss information to decouple packet loss from congestion. original TCP loss-recovery schemes have several inherited weakness which is even exaggerated in wireless network. Secondly. in-order and loss-free packet delivery. Spurious. variation of wireless channel further increases the burden of wireless TCP.

we present WiTracer. Designs should never break down original TCP semantics. Figure 1 : Architecture of WiTracer 4|Page . the Congestion Identifier module and the Opportunistic Recovery module. At receiver side the out-of-order and Spurious DATA issues are solved.and should support all mainstream TCP variants. to recover losses. we suggest that our solutions are regulated by the following principles: 1) Compatibility. which mitigates wireless-incurred RTO. it makes TCP more adaptable to wireless specifications. and also less dependable on using inefficient inherent TCP congestion control. avoid adding new header fields. 3) Scalability. Congestion Identifier seeks to combine both Round-Trip-Time (RTT) and Loss information to decouple packet loss from congestion. Our objective is to address the aforementioned issues thus to preserve a stable and desirable throughput for end-to-end wireless TCP. Opportunistic Recovery module proceeds local recovery using opportunistic single DupACK. and it can also react to the spurious DATA and ACK loss. Secondly. The designed modules should be kept coupling-free. 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. WiTracer intends to fill this gap. It contains two components: Congestion Identifier and Opportunistic Recovery. a novel solution to improve TCP performance over wireless network. 2) Stability. To make WiTracer stronger. or RTO. Architecture and methodology WiTracer Design :Our goal is to mitigate all the aforementioned drawbacks for wireless TCP. The architecture of WiTracer is shown in Figure given below. WiTracer consists of two main modules.Objective of the Application In this report. while at the sender side congestion identification and the rest of the drawback issues are tackled. cost-minimal and transparent to TCP. Any “radical” change to existing TCP congestion control scheme should be avoided to preserve network stability and TCP friendliness.

which also means that congestion is rather a rare event to be found in TCP. From left to right we show examples of Hungry RTO. loss and out-of-order are hardly correlated with congestion. then. Reno-based TCP also has following drawbacks which incur frequent throughput degradation. Note that Variation and ACK-loss may both cause Spurious DATA. when the receiver receives any out-of-order or lost packets. The value represents SEQ number of DATA (Sender). transmission delays will become fluctuated and unbounded which further results in frequent out-of-order packet delivery and RTO. designing an alternate approach to reduce the unnecessary invocations of TCP congestion control is important. with quantity equal to the current Congestion Window (CW) size. and should be treated differently WiTracer Operation Principle WiTracer is made up of two modules. Despite these problems. the congestion control is begun: CW size is reduced. Hereafter. and two possible causes of Spurious DATA. However in wireless networks. attenuation. if losses appear in conjunction with link layer recovery mechanisms. It is clear that these drawbacks either occur unexpected RTO or induce bandwidth wastage (marked in red). etc. Unfortunately. The two modules are: 5|Page . the majority of packet loss are originated from random wireless link transmission error because of various causes as fading. when sender receives more than 3 DupACKs. Moreover. and ACK number of ACK (Receiver). RTX-DATA just blindly reduces CW but such effort is in vain. Reno-based TCP cannot differentiate packet loss and out-of-order from congestion . Each sender can send new DATA packets. it will recognize this as a sign of network congestion.TCP Background TCP is designed to provide ordered and error-free packet transmission. These two modules should be employed in between the TCP sender and TCP receiver at both the ends. On the contrary. In reality. it will send DupACK packet whose ACK number is smaller than expected ACK number. and should be treated differently with packet loss. throttling DATA rate to avoid congestion. Figure 2 The above figure shows drawbacks in wireless TCP. upon previous ordered DATA being acknowledged (ACK) by the receiver. Then.

from the timestamp when identifier receives its ACK. the RTTi can be obtained by subtracting the timestamp when corresponding DATA packet is sent. Then. referring to the received inbound ACK packets. it measures whether the lost packets deviates too much from the previous RTT values. RTT >. If both requirements are fulfilled. whether their averaged RTT is greater equal to RTTThresh. the identifier will maintain a record entry for each flow. RTTmean + α . Such identification is specifically validated in DropTail-based queuing networks. WiTracer instantly employs a window whose size is equal to the current CW size. Loss. On the other hand. which is originated from TCP Timestamp Option. a general form of Low-pass filter of RTT is presented. The default value of α is set 0. and be delivered to the Opportunistic Recovery module to invoke local retransmission. SYN-ACK or first ACK is retransmitted. RTTvar + α. 4. M. this DupACK is recognized as an indicator of congestion. the identifier will add an entry to this record. Specifically. lossThresh and RTTThresh is given by: lossThresh = max{2 . To begin with. Therefore WiTracer combines both packet loss and RTT information to identify congestion. For RTTThresh. Equation (1) uses a parameter. and will be forwarded to further trigger congestion control with following 2 same DupACKs. Then. setting the ACK field to be equal to the ACK number of the packet and Loss field to be 0. Otherwise. < ACK. when identifier receives a DupACK. to denote the threshold of the proportion of lost packets in a CW (We set M = 0:25 in practice). RTTi is further smoothed using the exponential weighted moving average. Within this window. 3. 2. the Loss field of SYN-ACK will be set as 1. it will add a corresponding entry with Loss = 1. RTTmean = (1 -α) . In Equation (2) underneath. This also includes SYN-ACK which comes from TCP 3-way handshake.RTTi RTTvar = (1 -2α) . it will be identified as the normal wireless incurred packet loss.Congestion Identifier Neither RTT nor packet loss information is enough to recognize congestion individually. For lossThresh. Upon every received ACK packet i. checking for this DupACK together with its previous ACK entries. and also. which works as follows: 1. It is worth noting that if SYN.| RTTi – RTTmean | (2) 6|Page . as variations in RTT and Spurious packets induce inaccuracy. the identifier detects whether there exists at least lossThresh packets with Loss = 1.125 in the experiment. Upon receiving any ordered ACK. ⌊M × CW⌋} RTTThresh = RTTmean + 2RTTvar (1) where RTTmean and RTTvar are obtained using Equation 2 below.

then Spurious DATA 3 is simply dropped by Receiver-ware. with following DupACKs dropped.Opportunistic Recovery In WiTracer. Note that our Opportunistic Recovery module does not change the original TCP congestion control. Real Case Test Data Available and Performance Evaluation Simulation Preliminaries We implemented WiTracer using Network Simulator-2. 7|Page . We generate FTP traffic from the TCP source to the receiver. Therefore. and before recovered Spurious DATA arrives at Receiver-ware. It is worth noting that if DATA 4 comes before Spurious DATA 3. actually only a single DupACK (“opportunistic”) is enough to invoke retransmission for loss recovery. and is averaged from 50 trials. the real recovered Spurious DATA is correctly acknowledged since it comes after FilThresh in most cases. Sender-ware resends DATA 1 after the interval is expired. loss is identified at the first DupACK and henceforth is opportunistically replied. using single DupACK is already enough for efficient local recovery. However it also makes it less efficient to invoke loss recovery especially when congestion window is small. 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. we find that. In Spurious DATA case c). which has a wireless LAN interface to establish a wireless link to a TCP receiver. Dash-dot arrows represent DATA packets generated by Sender-ware local recovery. The network is composed by a wired link connecting the TCP source to a base station. we assume the original DATA packet 1 comes after local recovery initiated. Figure 3 Figure 3 shows WiTracer mitigation of drawbacks. Original DATA is acknowledged. and solid arrows are the DATA packets sent by the Sender. Opportunistic Recovery is based on a simple intuition: instead of using 3 DupACKs to initiate retransmission. Green term shows the side where WiTracer functions. For RTX-DATA Loss b). In d). in order to eliminate the randomness of simulation results. together with the simulation setup. Each data trace is kept running for 100 seconds. Then if both out-of-order and Spurious DupACK can be reduced at the receiver to utmost. For Hungry RTO a). and can mitigate drawbacks mentioned in previous Topic. but Spurious DATA is dropped since it is within FilThresh.

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

Figure 4 (a) Figure 4 (b) Figure 4 (c) Figure 4 (d) 9|Page .

WiTracer. “ ‘De-Randomizing’ congestion losses to improve TCP performance over wired-wireless networks. SACK TCP. S. Simulation results show that WiTracer outperforms existing benchmarks. and Y. On Telecommunications ’08. 2009. http://www. Dr. MNNIT. while Opportunistic Recovery provides a faster recovery rate of DupACK and mitigates several TCP drawbacks: Hungry RTO. pages 5-21. pages 424-428. 2011. a novel solution to improve TCP performance over wireless network. Congestion Identifier checks for each DupACK packet and implement local recovery. Symp.” ACM SIGCOMM CCR. “Simulation-based comparisons of Tahoe. RTX-DATA Loss. 2013. Mobile 10 | P a g e . 26. On Networking. W. J. vol. Jul. Aug. 2010  [3] S. Therefore. Biaz and N. J. It is composed by Congestion Identifier and Opportunistic Recovery.” in Proc. Reeve. pages 596-608. H.” IEEE/ACM Trans. WiTracer can be easily launched on mobile devices (Android/iOS) for various applications. Vaidya. Fall and S. 3.  [2] K. no. Lee.isi. References  [1] K. was proposed. Jun.  Class Instruction Materials. 13. Mayank Pandey. Int.  The Network Simulator: ns-2. Floyd.Conclusion The several major causes and occasions that result in TCP performance degradation were identified. vol. and Spurious DATA. “Improving TCP performance over wireless networks. Lien.