Network Working Group Yun Li Internet-Draft Qieli Liu Intended status: Informational CQUPT Expires: December 1, 2011 May 31, 2011 An Enhanced Congestion Control for TCP in Opportunistic Networks draft-yunli-atcp-00.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on June 31,2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Li Expires: December 1, 2011 [Page 1] Internet-Draft A-TCP/Reno May 2011 Opportunistic networks have attracted attention due to their inherent characteristics, such as long latency, low data rate, and intermittent connectivity. Extensive research has been conducted on opportunistic networks, including the architecture, and routing. However, few in the literature report the performance of TCP in opportunistic networks, especially in the case of Epidemic Routing. This document investigates the performance of TCP [1] in opportunistic networks with Epidemic Routing. Our results show that the Epidemic Routing in opportunistic networks degrades the performance of TCP because multicopy data packets cause duplicate ACKs, and in turn reduce the transmission rate of TCP. An enhanced congestion control for TCP, named A-TCP/Reno is proposed. A-TCP/Reno avoids the duplicate ACK problem caused by Epidemic Routing. Table of Contents 1. Introduction................................................2 2. Enhanced Congestion Control for The TCP in Opportunistic Networks ...............................................................3 2.1. The problem of TCP in opportunistic networks............3 2.2. Enhanced Congestion Control for The TCP.................4 3. Security Considerations......................................5 4. IANA Considerations.........................................5 5. Conclusions.................................................5 6. References..................................................6 6.1. Normative References....................................6 6.2. Informative References..................................6 1. Introduction Opportunistic networks [2], are defined as one type of challenged networks [3], which can be encountered in many environments, such as wildlife tracking: ZebraNet [4] and Shared Wireless Infostation Model (SWIM) [5], Pocket Switched Networks (PSNs) [6], vehicle network: CarTel [7], and opportunistic networks for developing areas such as DakNet[8]. Opportunistic networks have many unique characteristics different from the traditional networks, including high latency, low data rate, long queuing delays, limited resources including limited memory and processing capability, and intermittent connectivity mainly due to motion. These characteristics render the traditional network architectures and protocols ineffective. Li Expires: December 1, 2011 [Page 2] Internet-Draft A-TCP/Reno May 2011 Opportunistic networks transmit data from the source to the destination through forwarding data hop-by-hop intra node pairs. They do not require that the network be fully connected that fit the needs of realistic ad hoc networks and have significant influence on realizing pervasive computing [9]. Therefore, opportunistic networks have a variety of important applications in diverse situations. In the past, performance of flooding-based routing protocols was evaluated with UDP as the transport layer protocol [10, 11]. However, few have investigated the performance of TCP in opportunistic networks, especially when Epidemic Routing is implemented. TCP is an important transport layer protocol in Internet, supporting End-to-End reliable transmission and congestion control, and used by many Internet applications, such as FTP, Email, and Web services. Therefore, it is important to investigate the performance of TCP in opportunistic networks as well. In this document, we first discuss the performance of TCP with Epidemic Routing in opportunistic networks. The Epidemic Routing [12] in opportunistic networks degrades the performance of TCP due to multicopy data packets causing duplicate ACKs. Then an enhanced algorithm for TCP, which we call A-TCP/Reno is proposed to resolve the problem. 2. Enhanced Congestion Control for TCP in Opportunistic Networks In this section, the problem of TCP in opportunistic networks is discussed. Then enhancement for the TCP is given. 2.1. The problem of TCP in opportunistic networks Epidemic Routing for opportunistic networks makes message transmission transmitted in the network in many ways similar to the viral transmission. Under ideal conditions, such as unlimited bandwidth, buffer, and energy, Epidemic Routing can perform well. However, its performance is poor when TCP/Reno is implemented. Because of the mobility of nodes, opportunistic network may have a link failure which leads to intermittent connectivity, which in turn degrades network performance. Also because Epidemic Routing is a multipath routing scheme, there are possibly many copies of the same packets in the network which result in receiving multiple copies at the destination. The receiver must send an ACK upon receiving a message, regardless of whether they are duplicate messages or not, therefore the destination node would send multiple ACKs. At the same time, it is possible that the source node receives multiple copies of the ACK. Once the third duplicate ACK is received, the fast Li Expires: December 1, 2011 [Page 3] Internet-Draft A-TCP/Reno May 2011 retransmit algorithm will be triggered. As a result, the fast retransmit triggered by multipath routing rather than the actual data loss increases the overhead and degrades overall performance of the network. 2.2. Enhanced Congestion Control for The TCP As we noticed from the previous section, there can be a large number of duplicate packets in opportunistic networks when TCP/Reno is combined with Epidemic Routing. In order to improve the performance by decreasing the number of duplicate ACKs caused by multicopy data packets, we proposed an enhanced algorithm for the TCP. The details of A-TCP/Reno algorithm are shown in Figure 1. In TCP/Reno, the receiver must send an ACK upon receiving a packet, regardless of whether it is a duplicate packet or not. But in A- TCP/Reno, the receiver will check the packet and confirms in a self- adaptive manner. Only if it is a duplicate packet and also the time interval between Ti (the time of the packet received for the i-th time) and T0 (the time of the packet received for the first time) is greater than alpha*RTO ( is a fixed multiplier), or else if it is not a duplicate packet, the receiver will send an ACK. In opportunistic networks, different types of duplicate packets can be processed distinctively. We classify the duplicate packets into two groups: Group 1: isdup_==TRUE and Ti-T0 > alpha *RTO: A duplicate packet is received and the time interval between Ti and T0 is greater than *RTO. That is, the duplicate packet received is a retransmitted packet by the sender, rather than a duplicate packet caused by multipath routing. So it is necessary to send an acknowledgement for the packet. Group 2: isdup_==TRUE and Ti-T0< alpha * RTO: It is the opposite of Group 1. The received packet is a duplicate packet caused by multicopy data packets. In this case, no ACK is sent because a corresponding ACK has been sent when the TCP packet was received at the destination for the first time. In Group 1, the duplicate packet received at the destination is a packet retransmitted by the sender. That indicates that the source node has not received the corresponding ACK in time, or perhaps did not receive it at all. At this moment, if no acknowledgement was sent by the destination, this would result in retransmission repeatedly owing to no ACK arriving at the source. So it is necessary to send an acknowledgement. But in Group 2, the destination has sent an Li Expires: December 1, 2011 [Page 4] Internet-Draft A-TCP/Reno May 2011 acknowledgement for the packet whose copies are generated caused by multipath routing when received for the first time. Dropping them directly will reduce redundant packets and save resources, which also prevents possible congestion, such as fast retransmit triggered by three sequential duplicate ACKs. As a result, lower overhead and improved performance is expected. +--------------------------------------------------------------+ | 1: The time of a packet received for the first time ->T0; | | 2: The time of a packet received for the i-th time ->Ti; | | 3: The Sequence number of next packet expected ->Next; | | 4: The Sequence number of packet received now ->Seqno; | | 5: isdup->FALSE; | | 6: While a packet arrived at the destination{ | | 7: If Seqno < Next | | 8: isdup->TRUE; | | 9: Else if Seqno > Next but it has been received before | | 10: isdup->TRUE; | | 11: Else | | 12: Next->Seqno; | | 13: } | | 14: If isdup = FALSE or (isdup = TRUE and Ti-T0>alpha *RTO) | | 15: Send an ACK for the packet; | | 16: Else | | 17: Drop the packet directly; | +--------------------------------------------------------------+ Figure 1. The enhancement for the TCP. 3. Security Considerations The A-TCP/Reno block introduces no new security considerations beyond two nodes should trust each other before exchanging messages. 4. IANA Considerations This document has no IANA considerations. 5. Conclusions This document firstly discusses TCP performance in opportunistic networks especially when Epidemic Routing is used. Then an enhanced algorithm, A-TCP/Reno, is introduced. A-TCP/Reno requires that the destination does not send ACK for the duplicate messages. Since there are fewer redundant ACKs in the network and congestion control does Li Expires: December 1, 2011 [Page 5] Internet-Draft A-TCP/Reno May 2011 not occur unnecessarily (such as fast retransmit), this results in improved performance. 6. References 6.1. Normative References [1] Transmission Control Protocol, IETF RFC793, September, 1981. 6.2. Informative References [2] L. Pelusi, A. Passarella, M. Conti. Opportunistic networking: data forwarding in disconnected mobile ad hoc network. IEEE Communications Magazine, vol. 44 no .11, pp. 134-141, 2006. [3] K. Fall. A delay-tolerant network architecture for challenged internets. Proceedings of ACM SIGCOMM, pp. 27-24, August 2003. [4] P. Juang, H. Oki, Y. Wang, M. Martonosi, L.S. Peh, and D. Rubenstein. Energy-efficient computing for wildlife tracking: Design tradeoffs and early experiences with ZebraNet. ACM SIGPLAN Notices, vol. 37, pp. 96-107, 2002. [5] T. Small, Z.J. Haas. The shared wireless infostation model: A new ad hoc networking paradigm (or where there is a whale, there is a way). Proceedings of the 4th ACM Intl Symp on Mobile Ad Hoc Networking. Annapolis: ACM, 2003. pp. 233-244. [6] H. Pan, A. Chaintreau, J. Scott, R. Gass, J. Cmwcoft, and C. Diot. Pocket switched networks and human mobility in conference environments. Proceedings of the 2005 ACM SIGCOMM work shop on Delay-Tolerant Networking. Philadelphia: ACM. 2005. [7] B. Hun, V. Bychkovsky, Y. Zhallg, K. Chen, M. Goraczko, A. Miu, E. Shm, H. Balakrishnan, and S. Madden. CarTel: A distributed mobile sensor computing system. Proceedings of the 4th Intl Conf on Embedded Networked Senson Systems. Boulder: ACM, 2006. pp. 125-138. [8] A. Pentland, R. Fletcher, A. Hasson. DakNet: Rethinking connectivity in developing nations. IEEE Computer, vol. 37, no. 1, pp. 78-83, January 2004. [9] M. conti, S. Giordano. Multihop ad hoc networking: the reality. Communications Magazine, vol. 45, no. 4, pp. 88-95. 2007. Li Expires: December 1, 2011 [Page 6] Internet-Draft A-TCP/Reno May 2011 [10] Z.Jin, X. Zhao, Y. Luo, D.Zhao. Adaptive Priority Routing with Ack_Mechanism for DTN networks. Proceedings of Wireless Communications & Signal Processing, 2009.Nanjing: China, pp.1-5, Nov. 2009. [11] R. Subramanian, F. Fekri. Throughput analysis of Delay Tolerant Networks with finite buffers. Proceedings of 5th IEEE International Conference on Mobile Ad Hoc and Sensor Systems, 2008. Atlanta: GA, pp.790-795, Oct. 2008. [12] A. Vahdat and D. Becker. Epidemic routing for partially connected ad hoc networks. Technical Report CS-200006, Duke University, April 2000 Authors?Addresses Yun Li Wireless Network Laboratory, Chonqing University of Posts and Telecommunications, China Nan An District, Chongqing, China, 40065 Phone: 0086-23-62460218 Email: liyun@cqupt.edu.cn Qieli Liu Wireless Network Laboratory, Chonqing University of Posts and Telecommunications, China Nan An District, Chongqing, China, 40065 Phone: 0086-23-62460218 Email: liuql@cqupt.edu.cn Li Expires: December 1, 2011 [Page 7]