INTERNET DRAFT Fei Peng Beijing University of Posts and Telecomm. draft-fpeng-fcn-00.txt January 2000 A proposal to add Fast Congestion Notification to IP and Improve TCP Performance in Wireless and Mobile networks Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft 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. 1. Abstract This paper create a method using a simple implementation to inform the traffic source at a very early stage that the network is becoming overload or congested and to ask the source to slow down its transmission rate. For simplicity, the network only indicates congesition to the node where data transmission rate will be reduced or increased adaptively. For the consideration of asymmetric routing and to shorten long control delay time, the congestion notification message generated for the incipient congestion in the network should immediately routed back according to its source address. Upon receiving this message, the source terminal discards this message and immediately initiates its congestion control, then it sends message to tell the network node to stop adding it. To improve TCP performance in wireles and mobile networks, we assume packet losses in the network can not initiate congestion window reduction with this message to achieve separation of congestion control and loss Fei Experimental [Page 1] Draft-fpeng-fcn Addition of FCN to IP January 2000 recovery mechanism. Then, I mention that this Fast Congestion Notification should be created once the buffer size exceeds the prefixed threshold and still generated though upon packet losses due to congestion until the messages inform the source redution of congestion window reache it. However, in traditional wired networks, it is no need of disable packet losses to initiate congestion control and the FCN will not required to be generated after packet losses due to buffer overflow occurs for the packet losses are mainly due to congestion in such environment. It is most noted that the source address of following Fast Congestion Notification messages will remain the same as the first one in a window to avoid reducing the transmission rate of multiple TCP connections simultaneously and improve the fairness and performance either in wire or in wireless environent. 2. Conventions used in this document "FCN" indicates Fast Congestion Notification. "FCN threshold" indicates buffer threshold set for generating "FCN message". The mechanism proposed in this report is named as "FCN mechanism". "CWR" indicates Congestion Window Reduced bit in the IP header. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [ ]. 3. Introduction TCP is one of the few transport protocols that has its own congestion control mechanisms. TCP flow control mechanism is meant to slow down the source rate when the network becomes congested. Since it has no direct way of knowing when the network is congested and can only indirectly detect congestion by keeping track of how many packets are lost, congestion control has to be initiated after packet losses due to congestion have already happened. As for the burst and unpredictable nature of computer datagram traffic makes TCP difficult to control congestion without a significant loss of packets, great degradation in TCP performance may occur for burst losses may lead to global synchronization and throughput collapse, and they compromise the performance of delay sensitive traffic because packet retransmission for lost packets is scheduled with a back of delay equal to twice the current (estimated) round trip delay. Throughput decreases because the end-to-end delay increases. Besides, depending on when congestion hits, the drop of packets may come too late if the Fei Experimental [Page 2] Draft-fpeng-fcn Addition of FCN to IP January 2000 source has already sent out all the data it intended to. To avoid unnecessary packet drops and therefore avoid unnecessary delay for packets from low-bandwidth delay-sensitive TCP connections, an Explicit Congestion Notification is currently proposed by IETF group to inform the source node of the congestion occurrence by detecting incipient congestion from the intermediate routers. As an indication of congestion when the buffer had not yet overflowed, the ECN bit is set in the packet header when it arrives at the input port, then it is routed towards its destination. At the destination, the ECN bit is set in the next outgoing ACK packet and is turned around by the receiving terminal to the source. Thus, it has the same control loop as TCP flow control and the source has to wait a round- trip time before response to ECN messages. This long feedback delay of ECN message causes low buffer utilization and high requirement of larger buffer size though it gains the advantage of implementing in any asymmetric network. Implementing congestion control algorithm at source and processing congestion-related notification at receiver clearly need modification of TCP behavior at end systems. This paper proposes a new congestion avoidance mechanism to overcome above disadvantages. The structure of this mechanism comprises two basic parts: network congestion notification messages which indicates congestion according to buffer threshold and packet losses due to buffer overflow should immediately route congestion notification back base on source address of one of the forward packet; the congestion control initiated by congestion notification message is carried out at the source terminal. With this, each network node with asymmetric forward and backward path will gain benefits to avoid buffer overflow without the cost of long control loop; because the control loop is shortened, the buffer utilization is highly improved. The assumption of initiating congestion control by this Fast congestion notification can improve TCP performance in wireless and mobile networks for the unnessary window reduction by packet losses due to transmission errors is avoided by this message. 4. Assumption In this section, we describe some of the important assumptions that guided the desingn choices in this proposal. (1) In wireless and mobile networks, it is one of the premises of Fei Experimental [Page 3] Draft-fpeng-fcn Addition of FCN to IP January 2000 FCN mechanism that alll the end nodes in the experiment are FCN capable. And congestion control can only be invoked by FCN message. Packet losses whether it is due to transmission errors or congestion is not allowed to initiate window reduction. (2) With the above assumption, implementing FCN need not having to resort to "islands" of whether packet loss is due to transmission error or congestion. (3) It is assumed that each node in the network support the FCN mechanism to indicate congestion whether acket losses due to buffer overflow occurs or the prefixed threshold exceeds. (4) The transport protocol is capable and willing to participate in FCN in each transmitting packet. (5) It should be noted that in traditional wired networks, it is no need to disable packet losses to initiate congestion control since packet losses are mainly due to congestion. And also it is not required to generate FCN messages because of packet losses due to congestion. (6) Wherever in wired or in wireless networks, Asymmetric routing is likely to be a normal occurrence in the Internet. The path (sequence of links and routers) followed by the acknowledgment packets in the revers direction. 5. Fast Congestion Notification in IP We set out with the purpose of a shortened congestion control loop simultaneously possessing asymmetric applicability. The congestion notification message used in formerly proposed ECN mechanism should first travel to the receiver, at the receiver side, CE bit must extract from the IP header and then add to the TCP header, packets with this ECN bit set in the TCP header will then return back to the source to initiate congestion control. If this method is used to invoke congestion control at the source, it must take the source terminal a round-trip time to react and the TCP behavior in the receiver side have to be amended too though it solve the asymmetric problem. So, we propose that the congestion notification message should be immediately routed back according to its source IP address instead of forwarding to the receiver once it is generated for the incipient of congestion in the network. After returning to the source, it starts the congestion control and then be discarded. With this, the control delay time is largely shortened and the access node can act more quickly. As it is not required that the returned route of Fei Experimental [Page 4] Draft-fpeng-fcn Addition of FCN to IP January 2000 this message must be the same as forward path of its data packets, it can be used in any asymmetric networks which is very applicable for asymmetrically exists in almost all networks today. Since TCP congestion control itself bounds the mumber of packets that could be in the reiver buffer, it will make no modification of TCP behaviors at the destination terminal. The features of this part include: (1) In the intermediate network node, a mechanism for active queue management that has been proposed to detect incipient congestion in the ECN mechanism must be used in this scheme. For simplicity, at least one threshold should be set before the queue overflows. When the average queue length exceeds it or buffer overflow happens, it indicates the incipient of network congestion. And when the average queue length reduced below it and there is no packet loss due to buffer overflow occurs (for dropping packets makes buffer size reduce below the threshold), it indicates that the congestion in this node has released. That is, whenever the length of buffer in the network node exceeds or remains higher than FCN threshold or packet losses due to buffer overflow are detected, a FCN packet will be generated with FCN bit set for each forward incoming packet. (2) When the average queue length exceeds the FCN threshold or maitains higher than the threshold or just lost packets because of congestion, the mechanism is implemented by latching the source/destination IP address of the incoming packets, setting or unsetting FCN bit in the IP header, exchange the source address and destination address into the generated packet which has replicated the IP header from the forward passing packet, then insert it into the reverse direction stream. Even with the different backward path where its forward packets travel, the FCN packet will go back to the source and pass through access node because the destination address is identical to the source address. So it also has the advantage of applying this mechanism to asymmetric environment. Since the format of FCN packet is identical to that of IP header of the packet in the forward direction with the source and destination address exchanged and FCN bit set or unset, it remarkably saves network bandwidth with the limited FCN overhead as the length of the FCN packet is equal to the size of IP header. (3) For simplicity, and for the fairness considerations, the contents in the following FCN packets are the same as the that of the most previous one and only insertion performance is required, In this way, it also avoid multiple congestion window reduction of multiple transport connections which result in unnecessary idle state Fei Experimental [Page 5] Draft-fpeng-fcn Addition of FCN to IP January 2000 in the network. (4) The FCN message is generated and routed back until the CWR (congestion window reduced) message from the source is received. And then the router begin another period of FCN adding phase which includes: as soon as buffer size exceeds the prefixed threshold, the first FCN message is created with the procedure of replicating the IP header of the most current packet, exchanging the source and destination address and inserting to the backward path. The following FCN according to buffer occupacy and packet losses due to buffer overflow can then created by the replication of the first one and then directly insert to the backward routing line. (5) The only difference of FCN in wired environment and in wireless environment is that the FCN need not to be generated when packet losses due to buffer overflow occur. Since in wired environment, packet losses can also initiate the congestion window reduction. (6) The order of FCN generated in the network nodes does not orderly conform to data transmitting direction, The later router may create FCN packets earlier than the former routers in the forward direction. As soon as FCN is generated, it is immediately directed by feedback from the congestion node. When FCN packets travel through network, it is no need of examination in the backward network node. That is, the value of FCN field will not be changed or erased by the node as it travels through network in the backward direction. (6) TCP uses two windows in its flow control: one for the receiver flow control and the other for the network congestion control. The former bounds the number of packets that could be in the receiver buffer at any time. By sizing the receiver buffer equal to this window, buffer overflow at the receiver can be avoided, so no limit is placed on the size of the destination queue and FCN mechanism will not affect TCP behavior at the receiver. (6) The FCN requires individual network nodes to generate FCN packets and insert them into the network which then to be sent back to the access node, while in ECN, each node simply marks a bit in the packet header that passes through the node. In spit of the increased control complexity, FCN can provide marginally better performance than ECN. In any case of ECN mechanism, the reaction to the congestion signal is felt at the congested router only after a RTT. Even then the reduction in the source rate may not have been sufficient, in which case packets are still dropped and a new RTT has to go by before the rate is reduced again. This may also cause a very high number of unnecessary ECN messages for the effect of each ECN is visible to the source after RTT packet time during which the packets from the target Fei Experimental [Page 6] Draft-fpeng-fcn Addition of FCN to IP January 2000 source continue to be received at the previous high rate. While FCN mechanism can solve this problem for it guarantees the congestion control to be executed in current Round-Trip time by quickly response to the previous FBCN messages in the same window. Data transmitting rate has been reduced and congestion has been alleviated before a window of data arrive to the destination. This allow traffic to be kept under control using a limited Fast Congestion Notification messages. With the FCN, it is no need of any changes of the response to the FCN message in the receiver like ECN mechanism. Moreover, it has the advantage of implementation in any asymmetric networks because the destination address contained in FCN message is exchanged to the source address when it is inserted into the backward path. 6. Modification from the Transport Protocol Unlike the ECN mechanism, the Fast Congestion Notification need not the complex process in the phase of TCP initiation fot it does not change the behavior of the receiver. And in the TCP connection setup phase, it is not required that the source and destination TCPs to exchange information about their desire or capacity to use FCN. To differentiate ECN packet, the FCN packet use bit 5 to indicate congestion in the Ipv4 TOS octet. When TCP sender receives a FCN packet at the IP layer, it inform the TCP layer to initiate congestion control and discard this FCN packet. Then, the CWR bit in the Ipv4 TOS octet of bit 4 is used in the sending packet to inform the router that the source window has reduced. And it is time to disable the generation of FCN packets to wait for another period of FCN procedure. The FCN mechanism can not only avoid unnecessary packet drops for short or delay-sensitive TCP connections as ECN can, it has the effect on independence of TCP of packet loss as the indication of congestion. Since TCP use FCN message to invoke congestion control, whenever a packet loss occurs, only retransmission mechanism is used at that time which does not affect TCP data flow rate. This is very useful in wireless and mobile networks for the network itself has the function of distinguishing different source of packet losses. By informing the sender with FCN packets whenever the congestion loss occurs, packet losses due to transmission errors could not reduce TCP flow control window, which results in significant performance improvement. The TCP congestion window can only be reduced by FCN message, which is set due to congestion losses or the threshold exceeding. The additional requirement for the TCP source to react to multiple Fei Experimental [Page 7] Draft-fpeng-fcn Addition of FCN to IP January 2000 FCN is that is should not repeat the reduction of the congestion window more than once every window of data. The sender would react to the subsequent FCN only after the outstanding data before the sender entered into loss recovery phase upon receiving the first FCN bit have all bee acknowledged. In a window of data or every round-trip time, the TCP sets the CWR bit in the IP header of the first data packet sent after the window reduction for any reasons, that is, in wired environment, the TCP source reduce its window probably because of packet loss or FCN message and in wireless networks, the source TCP initiate congestion control by FCN message. The CWR bit is continuously set in the data packet until the the outstanding data before the sender reduces the congestion window have all been acknoledged. Thus, the Congestion Window Reduction is message is reliably delivered to the data receiver. The TCP follows existing algorithms for sending data packets in response to incoming ACKs. Multiple duplicate acknowledgement or retransmit timeouts only in charge of loss retransmission and is separated from window reduction. 7. Security Considerations With the FCN mechanism, the number of dropped FCN message should be small in the networks since multiple FCN messages set after buffer occupacy exceeds the threshold until the congestion window reduction message arrives. In the wireless and mobile networks, the FCN packets generated even with buffer overflow could guarantee the security of FCN when it is lost due to corruption or other reasons. 8. Conclusions Given the current effort to implement congestion avoidane mechanisms that do not depend on packet drops alone, the FCN mechanism proposed in this paper shortens the congestion control loop and improve the TCP performance by reducing the transmission rate of the least number of transport connections in the networks and enhance the fairness. In wireless and mobile networks, with the assumption that congestion control shall not be initiated by packet losses, The FCN message realize the separation of different source of packet losses and improve TCP performance in wireless and mobile networks. This would be possible with the increased deployment of applications and transport protocols. Fei Experimental [Page 8] Draft-fpeng-fcn Addition of FCN to IP January 2000 9. References [RFC791] J. Postel, internet Protocol, RFC 791, September 1981. [RFC793] J. Postel, Transmission Control Protocol, RFC 793, september 1981. [Floyd93] S. Floyd and V.Jacobson, Random early detection gateways for congestion avoidance, IEEE/ACM Trans. on Networking, Vol.1, no.4, pp.397-413, August 1993. [ECN] K.K.Ramakrishnan and Sally Floyd, Aproposal to add Explicit Congestion Notification (ECN) to IP, Internet Draft-kksjf-ecn-03.txt [PJ98] Fei Peng, Jian Ma, An Effective Way to Improve TCP Performance in Wireless and Mobile Networks, Invention Report submitting to Nokia, December, 1998. [NS97] Paolo Narvaez and Kai-Yeung Siu, An Acknowledgment Bucket Scheme for Regulating TCP Fow over ATM, Globcom 1997. [RJ90] k.k. Ramakrishnan and Raj Jain, "a Binary Feedback Scheme for Congestion Avoidance in Computer Networks", ACM Transactions on Computer Systems, Vol.8, No.2, pp. 158-181, May 1990. 10. Author's Addresses Fei Peng Beijing University of Posts and Telecommunications. Phone: 010-62283761 Email: fpeng@bupt.edu.cn Fei Experimental [Page 9]