Implementation of TCP Algorithms in Combination with NACK Feature of Adhoc Networks

Transcription

1 5 JEST-M, Vol 2, Issue 2, 2013 Implementation of TCP Algorithms in Combination with NACK Feature of Adhoc Networks Medha Dalal 1, Vivek Mishra 2 1 Assistant Professor, Department of Information Science, MVJ College of Engineering, Bangalore. 2 B. E. Student, Department of Information Science, MVJ College of Engineering, Bangalore Abstract Internet traffic today is heavily dependent on Transmission Control Protocol, which has proved its wide-spread use and popularity well since inception. Performance characteristics of TCP are defined by the congestion control algorithm it employs. Currently there is no single congestion control approach for TCP that can be universally applied to all network environments. This paper presents the implementation of two different TCP versions in software, namely TCP Tahoe and TCP Reno along with NACK feature of Adhoc Networks. We share the results obtained at the transmitting and receiving ends. Keywords- TCP, Congestion Avoidance, Fast Recovery, NACK 1. INTRODUCTION While internet usage has grown tremendously in the last decade, network protocols have not scaled with that growth. New trends in multi-media communication deploy real time traffic that does not rely on TCP. This non-tcp traffic doesn t share the available bandwidth fairly with traditional TCP/IP Internet traffic. Multi-media traffic also does not perform congestion control in TCP friendly manner. Together, these phenomena can lead to starvation of TCP and congestion collapse [1]. Even though TCP has been around for so many years [2], research is still being carried out in improving various TCP versions with new features or improving TCP performance under different network environments. Surveys are being carried out from time to time to evaluate the effectiveness of various TCP-friendly approaches. One of the recent surveys [3] indicates that the research in this area has shifted from avoidance of congestion collapse to effective utilization of available network resources in diverse network environments be it wired or wireless. Based on the survey and suggestions from [3], we tried to implement congestion control mechanism of TCP-Tahoe (slow start, congestion avoidance and fast retransmit) as well as Fast Recovery algorithm of TCP-Reno to overcome the inefficient use of network under TCP-Tahoe. We also extended the reporting abilities of the receiver by introducing Negative Acknowledgement (NACK) transmission control character widely used in Adhoc Networks. The rest of the paper is organized as follows: Section 2 describes the problems of congestion control, context of design and our motivation behind this work. Section 3 discusses implementation details. Section 4 shares the results under various evaluation techniques. Section 5 concludes with some of the open issues and challenges along with the summary of results obtained. 2. DESIGN One of the main principles of congestion control is avoidance. TCP tries to detect signs of congestion before it happens and accordingly it tries to reduce or increase the load into the network. The alternative of waiting for congestion and then reacting is much worse because once a network saturates, it does so at an exponential growth rate and reduces overall throughput enormously. 2.1 Slow-Start Slow-start [4] is one of the algorithms that TCP uses to control congestion inside the network, also known as the exponential growth phase as shown in Fig. 1 below. Figure1. Working of Slow Start Algorithm When a connection is established, TCP treads lightly at first to assess the bandwidth of the connection and to avoid overflowing the receiving host or any other devices or links in the path.

2 6 JEST-M, Vol 2, Issue 2, 2013 Slow-start works by increasing the TCP congestion window each time the acknowledgment is received. It increases the window size by the number of segments acknowledged. This happens until either the amount of data being sent per burst reaches the size of the receive window on the remote host or an acknowledgment is not received for some segment. If a loss event occurs, TCP assumes that it is due to network congestion and takes steps to reduce the offered load on the network. Slow Start is actually not very slow when the network is not congested and network response time is good. 2.2 Congestion Avoidance Once a loss event has occurred or the receiver threshold has been reached, slow start algorithm is no longer used and flow control is governed by the receive window. Now, TCP enters the congestion avoidance [4] or linear growth phase. At this point, the window is increased by 1 segment for each Round Trip Time (RTT). This continues until a loss event occurs. At any time during transmission, congestion could still occur on a connection. If this happens (evidenced by the duplicate ACKs or NACKs and hence the need to retransmit), a congestion avoidance algorithm is used to reduce the send window size temporarily, and to grow it back toward the receive window size. In general, congestion avoidance algorithms exploit the additive increase, multiplicative decrease mechanism of TCP to avoid congestion by trying to force the sender hosts to reduce their congestion windows. 2.3 Fast Retransmit Fast Retransmit [4] is an enhancement to TCP which reduces the time a sender waits before retransmitting a lost segment. A TCP sender uses a timer to recognize lost segments. If an acknowledgement is not received for a particular segment within a specified time (a function of the estimated Round-trip delay time), the sender assumes that the segment is lost in the network, and retransmits the segment. Duplicate acknowledgement is the basis for the fast retransmit mechanism which works as follows: A TCP receiver should send an immediate duplicate ACK when an out-of-order segment arrives. The purpose of this ACK is to inform the sender that a segment was received out-of-order and which sequence number is expected. From the sender's perspective, duplicate ACKs can be caused by a number of network problems. First, they can be caused by dropped segments. In this case, all segments after the dropped segment will trigger duplicate ACKs. Second, duplicate ACKs can be caused by the re-ordering of data segments by the network depending on the routing path chosen. Finally, duplicate ACKs can also be caused by replication of ACK or data segments by the network. If the receiver can re-order segments, it should not be long before the receiver sends the latest expected acknowledgement. Typically no more than one or two duplicate ACKs should be received when simple out of order conditions exist. However, if more than two duplicate ACKs are received by the sender, it is a strong indication that at least one segment has been lost. The TCP sender will assume enough time has lapsed for all segments to be properly re-ordered by the fact that the receiver had enough time to send three duplicate ACKs. Figure2. Working of Fast Retransmit When three or more duplicate ACKs are received, the sender does not even wait for a retransmission timer to expire before retransmitting the segment as shown in Fig Fast Recovery After the fast retransmit algorithm sends what appears to be the missing segment, the "fast recovery" algorithm governs the transmission of new data until a non-duplicate ACK arrives [5]. A TCP receiver should send an immediate ACK when the incoming segment fills in all or part of a gap in the sequence space. This generates more timely information for a sender recovering from a loss through a retransmission timeout, a fast retransmit, or an experimental loss recovery algorithm, such as NewReno [6]. Since the Fast Retransmit algorithm is used when duplicate ACKs are being received, the TCP sender has implicit knowledge that there is data still flowing to the receiver. The reason being, duplicate ACKs can only be generated when a segment is received. This is a strong indication that serious network congestion may not exist and that the lost segment was a rare event. So instead of reducing the flow of data abruptly by going all the way into Slow Start, the sender only enters congestion avoidance mode. Rather than start at a window of one segment as in Slow Start mode, the sender resumes transmission with a larger window, incrementing as if in congestion avoidance mode. This allows for higher throughput under the condition of only moderate congestion. 2.5 NACK Generally all TCP schemes use cumulative acknowledgements ACKs for error recovery and congestion control. As each packet is received at the receiving end, the receiving host sends an acknowledgement back to the transmitting host. If there is any error, like packet dropped/lost, the transmitting host does not receive an acknowledgement for that packet. Then, the transmitting host retransmits that packet.

3 7 JEST-M, Vol 2, Issue 2, 2013 If a number of expected ACKs are not received at the sending end, TCP assumes that network is congested and reduces the transmission rate. Studies of Internet traffic have also shown that upto 40% of packets on the internet are control packets like SYN, ACK, FIN etc. with major chunk going to ACKs [7]. Even though one can argue that ACKs do not consume much bandwidth, they do consume significant processing resources from load network devices like routers. They also pose significant overhead on small wireless devices (PDAs) which have limited power. Therefore, it is desirable to reduce acknowledgement traffic. In the proposed design, the receiver, upon detecting a lost packet, sends a negative acknowledgement (NACK) to the transmitting host, thereby asking the transmitting host to retransmit the missing packet. The congestion window for the network is adjusted based on the number of NACKs. For the implementation work undertaken, we devised a simple negative acknowledgement to begin with in the protocol without distressing about round-trip timer as shown in Fig. 3. receiving an acknowledgment (ACK), while the receiver's advertised window (rcvwindow) is a receiver-side limit on the amount of outstanding data. The minimum of congwindow and rcvwindow governs data transmission. Another state variable, the slow start threshold (ssthresh), was used to determine which algorithm controls data transmission - the slow start or the congestion avoidance algorithm. The slow start algorithm is used when congwindow < ssthresh, while the congestion avoidance algorithm is used when congwindow > ssthresh. When congwindow and ssthresh are equal, the sender may use either slow start or congestion avoidance. We always start with slow start algorithm by default. 3.1 Architecture Fig. 4 shows the architectural diagram of the proposed design. Router Sender Pkt 1 Receiver ACK/NAC ACK/NAC Node N Pkt 2 Pkt 3 Transmitting Pkt 5 Pkt 6 Pkt 4 NAC K ACK/NACK Router Node N ACK/NAC Node N Data Channel Figure3. Working of Negative Acknowledgement 3. IMPLEMENTATION We used the Java Remote Method Invocation (RMI) system to develop our prototype software. RMI easily provided for remote communication [8] between our programs on transmitting host and receiving host. Two variables were used in the code for each TCP perconnection state congwindow and rcvwindow. The congestion window (congwindow) is a sender-side limit on the amount of data the sender can transmit into the network before Figure4. Architectural view of the proposed design Following modules were implemented to test the design concepts discussed in the earlier section TCP Host to host Network module: Host-to-host principle originally means that the hosts do not rely on any kind of explicit signaling from the network. The TCP Tahoe and TCP Reno algorithms implemented during this research, allowed senders to detect loss events and congestion state. We were able to measure the loss rate, the RTT, bottleneck buffer sizes, and congestion level.

4 8 JEST-M, Vol 2, Issue 2, Congestion Collapse module: This module primarily dealt with TCP sender s estimate of the number of data packets the network can accept for delivery, without becoming congested. In the special case where the flow control limit (rcvwindow) is less than the congestion control limit (congwindow) the former is considered a real bound for outstanding data packets. Although this is a formal definition of the real TCP rate bound, we only considered the congestion window as a rate limiting factor, assuming that in most cases the processing rate of end-hosts is higher than the data transfer rate that the network can potentially offer Congestion Avoidance & Packet Recovery Module: The purpose of this module was to reduce consumption of network resources in complex congestion situations. This expectation of course, rests on the assumption that congestion states, as deduced from each detected loss, are independent. However, this is not really true. All packet losses from the original data have a high probability of being caused by a single congestion event. So actually, the second and third losses from the same transmission should be treated only as requests to retransmit data and not as congestion indicators. Moreover, reducing the congestion window did not guarantee the instant release of network resources. All packets sent before the congestion window reduction, are still considered in transit. Before the new congestion window size becomes effective, any additional rate reduction policies should not be actually applied. We decided to reducing the congestion window only once per one-way propagation delay or by approximately RTT/ Sample Pseudo Code int lastbytesent=-1 int last ByteAcked=-1 int congwindow= [some value] int sendmode= SLOW-START int timer= 3 int ssthresh=65535 gettotalbytestransmitted() return (lastbyteacked+1) processacks(tcpsegment[] acks) if(ack[i]==null) Break if(sendmode==slowstart) processackslowstart(ack[i]) if(sendmode==congavoid) processackcongestionavoidance(ack[i]) if(lastbytesent==lastbyteacked) resetmonitoringvariables() else ProcessAckSlowStart() If(dupAck) return false else if(timer<0) onexpiredtimeouttimer() update congestionwindowsize If(congWindow>ssThresh) sendmode=cong-avoid processackcongestionavoidance() if (!duplicate Ack ) increment congwindow linearly reset monitoringvariable() dupack=0 timer=3 onexpiredtimeouttimer() ssthresh=congwindow/2 reset congwindow to oldvalue sendmode=slowstart send(tcpsegment[] segment, int rcvwindow,bool lostpacket) segmentarray=null segment[0]= new TCPSegment(lastByteSent +1,1) update lastbytesent

5 9 JEST-M, Vol 2, Issue 2, 2013 During congestion avoidance, congwindow is incremented by 1 full-sized segment per RTT. Congestion avoidance continues until congestion is detected. The sequence diagram of the host to host connectivity and exchanges is shown in Fig. 5 below. Figure5. Sequence Diagram of the proposed design 4. EVALUATION AND RESULTS Figure7. Snapshot of status on the receiving end Fig. 6 shows the normal operation with the implementation of the TCP Tahoe or TCP Reno versions and results on the sender side with router information as well as status of packets. Fig. 7 shows the implementation of NACK in our design. To reduce the ACK traffic, we did not send ACKs for packets received, instead we sent NACK when a particular packet was not received in a pre-fixed amount of time. When a packet is lost, in this case, packet 4, receiver waits for three RTPs, displaying WAIT status and when the packet is not received after 3 RTPs, NACK is sent. Fig. 8 shows the size of congwindow and SSThresh and implementation of slow start algorithm. When ACKs are received, congwindow size is doubled every time. Fig. 9 charts the results observed for TCP Tahoe and TCP Reno algorithms with various changes in the bit error rate (BER) of the transmission line. Both versions performed on par with each other when the losses were very small or very high. However, TCP Reno gave better throughput in the inbetween situation when BER was in the range of 10 to 20%. Figure6. Snapshot of status on the transmitting end

6 10 JEST-M, Vol 2, Issue 2, Figure8.Implemetation of Slow-Start implementations took longer to detect one packet loss. Slow-start assumes that unacknowledged segments are due to network congestion. While this is an acceptable assumption for many networks, segments may be lost for other reasons, such as poor data link layer transmission quality. Thus, slow-start performs poorly in situations with low reception, such as wireless networks. The slow-start protocol also performs badly for short-lived connections. Reno performed very well over TCP Tahoe when the packet losses were small. But when there were multiple packet losses in one window, Reno s performance turned out to be almost the same as Tahoe under conditions of high packet loss. This is due to the fact that, if there is a multiple packet drop then the first information about the packet loss comes when the transmitting node receives the duplicate ACKs. But the information about the lost second packet comes only after the ACK for the retransmitted first segment reaches the sender after one RTT. It was also noted that if the window is very small when the loss occurs, then we never receive enough duplicate acknowledgements for a fast retransmit and had to wait for a coarse timeout. This made it difficult to detect multiple packet losses effectively. This issue is overcome slightly by the usage of NACKs. Figure9. Comparison of results 5. CONCLUSION Following observations were made during the implementation and testing phase of the algorithms. TCP Tahoe is supposed to take one Timeout interval for the detection of one packet loss. However, most In general, it has been observed [3] that if the delay patterns change because of non-congestion-related factors, these algorithms suffer from efficiency and fairness degradation. Time constraints precluded further exploration of NACK with TCP wherein the congestion window for the network can be adjusted in response to the receipt of NACK. The congestion window could be controlled with the help of two timers A missing packet timer at the receiver which gets set when NACK is sent and a retransmission time-out timer at the transmitting end. The paper discussed and implemented basic algorithms that build a foundation for the host-to-host congestion control principles of TCP. The first implementation of TCP-Tahoe, introduced the basic technique of gradually probing network resources and relying on packet loss to detect that the network limit has been reached. Although, this technique solves the congestion problem, it creates a great deal of inefficient use of the network. Hence, TCP-Reno was implemented which refines the core congestion control principle by making more optimistic assumptions about the network. We also extended reporting abilities of the receiver by using negative

7 11 JEST-M, Vol 2, Issue 2, 2013 acknowledgement which cuts down on control traffic and still allows the sender to retransmit the lost packet. While research is being carried out to fine tune the existing TCP for high performance, we also see proliferation of non- TCP-based streaming media applications generating large volumes of traffic sharing Internet routers with TCP-based traffic. Since these applications do not implement TCP-like congestion control functions, they pose a real threat to TCP performance [9]. TCP continues to evolve as an effective transport layer protocol for the Internet. There have been several modifications to the core congestion control algorithms in TCP namely, TCP-SACK, Westwood, Vegas, Illinois, Africa, C-TCP, TCP-AR to name a few. There are also extensions to TCP [10] which are realized as options that can be added to the TCP header if the host wishes to do so. They try to mitigate some of the problems TCP faces due to faster networks. Although the performance dynamics of TCP over traditional networks are relatively well understood, the research community is only beginning to explore the TCP performance implications for the emerging and future networking environment which pose challenges of mobility and wireless connectivity. REFERENCES [1] J. Widmer, R. Denda, and M. Mauve, A survey on TCP-friendly congestion control, IEEE Network, vol. 15, no. 3, pp , May/June [2] J. Postel, RFC793 transmission control protocol, RFC, [3] A. Afan asyev, N. Tilley, P. Reiher, and L. Kleinrock, Host-To-Host Congestion Control for TCP, IEEE Communication Surveys and Tutorial vol.12, no. 3, pp , 3 rd quarter [4]M. Allman, V. Paxson, W. Stevens, RFC2581 TCP Congestion Control RFC, 1999 [5] M. Allman, V. Paxson, E.Blanton, RFC5681 TCP Congestion Control RFC, 2009 [6] K.-C. Leung, V. Li, and D. Yang, An overview of packet reordering in transmission control protocol (TCP): problems, solutions, and challenges, IEEE Trans. Parallel Distrib. Syst., vol. 18, no. 4, pp , April 2007 [7] N. Seddigh, B. Nandy, and J. Salim, System and method for a negative acknowledgement-based transmission control protocol, US Patent, patent - 7,035,214, 2006 [8] D. Reilly and M. Reilly, Professional Java Network Programming, 2 nd ed., Addison-Wesley, 2009 [9] M. Hassan and R. Jain, TCP performance in future networking environments, IEEE Communications Magazine, pp. 51, April 2001 [10] L. Peterson, and B. Davie, Computer Networks A systems approach, 3 rd ed., Morgan Kaufmann, 2003