Internet DRAFT - draft-fpeng-fcn

draft-fpeng-fcn



INTERNET DRAFT 						     Fei Peng 
						Beijing University of 
   						   Posts and Telecomm.
             						       Jian Ma
                                                 Nokia Research Center
draft-fpeng-fcn-03.txt					  January 2001



	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 wireless 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 and Jain			Experimental		        [Page 1]


Draft-fpeng-fcn		   Addition of FCN to IP  	     January 2001


   recovery mechanism. The Fast Congestion Notification should be created 
   once the buffer size exceeds the prefixed threshold and still generated 
   upon packet losses due to congestion until the messages inform the 
   source of congestion window reduction reach it. However, in traditional 
   wired networks, it does not need to disable packet losses to initiate 
   congestion control and the FCN will not required to be generated when 
   buffer overflow occurs because packet losses are mainly due to congestion. 
   It is noted that the source address of the following Fast Congestion 
   Notification messages may remain the same as the first one in a window to 
   avoid reducing transmission rate of multiple TCP connections simultaneously 
   and improve the fairness performance in both wire and wireless networks. 

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 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 and Jain			Experimental		        [Page 2]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001



   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 since the unnecessary 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 and Jain			Experimental		        [Page 3]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001



   FCN mechanism that all 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 are 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 is in the 
   reverse 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 and Jain			Experimental		        [Page 4]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001



   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 might 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. 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. 
   (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 and Jain			Experimental		        [Page 5]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001



   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 and Jain			Experimental		        [Page 6]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001


   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 and Jain			Experimental		        [Page 7]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001


   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 and Jain			Experimental		        [Page 8]


Draft-fpeng-fcn		   Addition of FCN to IP  	    January 2001


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

   Jian Ma
   Nokia Research Center
   Email: Jian.ma@nokia.com









	




Fei and Jain			Experimental		        [Page 9]