Internet Draft Fei Peng draft-fpeng-ecn-03.txt Beijing University of posts and telecomm. Jian Ma Nokia Research Center January 2001 A proposal to apply ECN into 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 is 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 is 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 TCP congestion control has been developed on the assumption that congestion in the network to be the only cause for packet loss. Thus, it drops its transmit window upon detecting a packet loss. In the presence of high error rates and intermittent connective characteristic of wireless link, these results in an unnecessary reduction in link bandwidth utilization for packet losses are not mainly due to congestion. Current ECN proposal proposed by IETF obtains a part separation of congestion control and packet losses with the purpose of preventing unnecessary packet drops due to buffer overflow. However, network Fei and Jain Experimental [Page 1] Draft-fpeng-ecn Apply ECN to Wireless January 2001 congestion can not be completely avoided and because of the losses of ECN by corruption and congestion, ECN will have to interact with the existing congestion control mechanism in TCP. This paper provides an effective way to improve TCP performance in wireless and mobile networks and cooperate ECN into such environment. Upon each dropped packets due to buffer overflow or the RED routers, an ISQ (ICMP Source Quench) is generated and sent back to the source of each dropped packet. The approach reduces congestion losses and the reaction time to congestion in the network. With the ECN control, network congestion is alleviated. When CE bit can be marked, no ISQ is required to be generated and ISQ messages created will not cause wasting of bandwidth. To ensure system more secure in case of losses of ECN or ISQ messages, a window threshold is calculated to allow that packet losses should initiate window reduction during times without ISQ and ECN messages coming back. It is important to note that this method is simple to implement for it makes minimal modification of current systems. 2. Introduction Congestion control is one of the key mechanisms to accommodate the increasingly diverse range of services and types of traffic in the Internet. Initially Internet was intended to support best-effort service, and TCP congestion control method that was actually implemented has been developed on the assumption that the network would be treated as a black box. This means that the end nodes do not exercise control by directly ascertaining the state of routers and transmission line, but rather regulate the traffic by inferring the network load indirectly from packet loss and response time fluctuations. In wired networks, this may not induce serious problems as packet losses are mainly due to congestion. However, in the presence of high error rates and intermittent connective characteristic of wireless links typically like wireless and mobile networks or the satellite environment, this reliance on packet drop as an indication of congestion causes a significant degradation in TCP performance, for TCP reacts to packet loss as it would in the wired environment: it drops its retransmit window size before retransmiting packets, initiates congestion control or avoidance mechanisms and resets its retransmission timer, thereby result in an unnecessary reduction in link bandwidth utilization, which causing poor throughput and very high interactive delays. Recently, several schemes have been proposed to alleviate the effects of non-congestion-related losses on TCP performance over networks that have wireless or similar high-loss links. One of the researches concerns on improvement of transport underlying protocol stacks. For example, there have been several proposals for Fei and Jain Experimental [Page 2] Draft-fpeng-ecn Apply ECN to Wireless January 2001 reliable link-layer protocols as forward error correction (FEC) and retransmission of lost packets in response to automatic repeat Request (ARQ) messages. However, it is the main worry about link- layer protocols that an adverse effect on certain transport-layer protocols such as TCP is very possible. Another solution of network layer protocol called snoop protocol is proposed to cache packets at the base station and perform local retransmissions across the wireless link. Like link-layer solutions, the snoop approach could also suffer from not being able to completely shield the sender from wireless losses. In practice, with the enhancement of TCP underlying protocols, the link error rate will still remain 1E-6 bits/sec. So it is essential to give a solution in TCP protocol stack. Several schemes modified at transport layer have been proposed to alleviate the effects of non-congestion-related losses on transport performance. The indirect-TCP is one of the first protocols to distinguish different losses by splitting a TCP connection between a fixed and mobile host into two separate connections at the base station, a more optimized wireless link-specific protocol tuned for better performance can be used over a one-hop wireless link. The advantage of the split connection approach is that it achieves a separation of flow and congestion control of the wireless link from that of the fixed network. However, there are some drawbacks of this approach such as loss of semantics, application re-linking and software overhead, etc. And there is no need to sacrifice the semantics of acknowledgments in order to achieve possible good performance. As lost packets can be simply divided into congestion-related losses and non-congestion-related losses, an ELN protocols can be used to differentiate the packet loss by adding an explicit loss notification option to TCP acknowledgments when a packet is dropped on the wireless link. Future cumulative acknowledgments corresponding to each lost packet must be always marked to identify that a non- congestion-related loss has occurred, then the sender may perform retransmissions without invoking the associated congestion-control procedures. In practice, this algorithm brings burden to the implementation nodes for judgment is required for each dropped packets and each lost packet due to transmission errors needs marking otherwise it will invoke congestion control. Additionally, it might be difficult to identify which packets are lost due to errors on lossy link, for example, it may be hard to determine the connection that a corrupted packet belongs to since the header could itself be corrupted. This paper provides a mechanism used in wireless and mobile networks. Like ELN, it is a mechanism by which Fei and Jain Experimental [Page 3] Draft-fpeng-ecn Apply ECN to Wireless January 2001 the reason for the loss of a packet can be communicated to the TCP sender. In particular, it provides a way by which senders can be informed that a loss happened because of reasons related to congestion), it is very easy to identify which packets are lost due to buffer overflow or RED mechanism in routers. The window threshold set to avoid unnecessary reduction of window size by Packet losses ensure that most of the times the congestion control mechanism is invoked by ISQ or ECN. 3. Current ECN proposal in IETF Bits 10 and 11 in the IPV6 header are proposed respectively for the ECT(ECN Capable Transport indicator) and CE (Congestion Experienced indicator). Bits 6 and 7 of the IPV4 header TOS field are also proposed as the ECT and CE placeholders respectively. TCP header is modified to add an additional flag, the ECN Echo flag, to notify the sender (from the receiver) that it is contributing to congestion. The flag's bit-space is borrowed from the reserved field in the TCP header. This bit is also interchangeably referred to as the ECT bit in this text. The ECT bit is set by the sender end system if both the end systems are ECN capable. This is confirmed in the pre-negotiation during the connection setup phase in TCP. Packets encountering congestion are marked (CE bit) by a router on their way to receiver end systems (from sender end systems), with a probability proportional to their bandwidth usage following the procedure used in RED [RFC2309] routers. When the receiver end system receives packet with CE and ECT bits set, it informs the sender end system that it is contributing to congestion by the setting of ECT bit in the ACK packet. The sender end system reacts by halving the congestion window upon receiving the ACK packet. And it reacts only once to ECT messages per in-flight window of messages. 4. Limitations of the Current ECN Proposal in wireless/mobile networks [RFC 2481] It is assumed that the participating routers are capable of RED or some other active queue management mechanism. In such a router, a packet has a probability of being dropped where this probability is dependent on average queue size. Because of the complex condition of the networks, packet drops due to buffer overflow can not be completely prevented with ECN mechanism, in addition, ECN itself will be lost by congestion or the corruption. Fei and Jain Experimental [Page 4] Draft-fpeng-ecn Apply ECN to Wireless January 2001 According to above assumption, it is most required that ECN proposal shall coupled with congestion control mechanism in TCP. In networks over imperfect links where packet losses are not mainly due to congestion, the unnecessary reduction of throughput will occur for the congestion window has been shielded half before ECN could come back. It should mention that Current ECN mechanism does not have to change any way with our proposal at the transport layer. 5. ICMP Source Quench All gateways must contain code for sending ICMP Source Quench messages when they are forced to drop IP datagram due to congestion. Although the Source Quench mechanism is known to be an imperfect means for Internet congestion control, and research towards more effective means is in progress, Source Quench is considered to be too valuable to omit from production gateways. [RFC 1009] There is some argument that the Source Quench should be sent before the gateway is forced to drop datagram. For example, a parameter X could be established and set to have Source Quench sent when only X buffers remains. Or, a parameter Y could be established and set to have Source Quench sent when only Y per cent of the buffers remain. Two problems for a gateway sending Source Quench are (1) the consumption of bandwidth on the reverse path, and (2) the use of gateway CPU time. To ameliorate these problems, a gateway should be prepared to limit the frequency with which it sends Source Quench messages. This may be on the basis of a counter (e.g., only send a Source Quench for every N dropped datagrams overall or per given source host), or on the basis of a timer (e.g., send a Source Quench to a given source host or Overall at most once per T milliseconds). The parameters (e.g., N or T) must be settable as part of the configuration of the gateway; How to give a suitable value of N or T in practice is also a problem. The [draft-salim] proposal concerns: ISQ message is generated by the intermediate RED router when it capture a packet with ECT bit set by the active queue management. Before the origination of the ISQ, the packet, which was chosen by RED probability, should be marked if it has not already marked. If the ECT bit is not set, the packet will be dropped whether RED chooses it or the average queue size goes above the maximum threshold. The purpose of this approach is to reduce the reaction time to congestion in the network and provide multilevel congestion feedback. In the following section, we Fei and Jain Experimental [Page 5] Draft-fpeng-ecn Apply ECN to Wireless January 2001 propose our ISQ mechanism to fit wireless and mobile environment. 6. Source Quench in Wireless/mobile networks While there are some applications/environments where it might be highly advantageous for the sender to receive some indication of congestion without having to wait a roundtrip time, this is not the common case. Source Quench packets add traffic in the reverse direction on what might be a congested path. Even with multilevel function of ISQs, the congestion window and the slow start threshold value are only halved at TCP source. Without the corresponding reaction of the source behavior, the multilevel ISQ lose its significant. Moreover, if threshold is set appropriately lower, ECN is also to be considered effective to alleviate network congestion in time. So, this section propose the ISQ messages are not required to be generated if only ECN can be set by the RED or other queue mandation without the packet being dropped in such case. Only upon the dropping of packets due to buffer overflow or queue management without ECN, ISQ messages are sent back to the corresponding sources. The algorithm in the router can be described as follows: If the incoming message causes average queue size go above maximum threshold or causes buffer overflow, the packet is dropped and an ISQ then sent back to the source of the incoming packet. If the incoming message causes the average queue to go between the minimum and maximum thresholds then: If the RED probability picks this packet then: If the ECT bit is set and the CE bit is not already marked then: Mark the packet (CE bit) Else if RED chooses this packet and ECT bit is not set then: Send an ISQ back and drop the packet. As long as ECT bit is set, CE bit is marked in most of times when condition permits. And also with ECN mechanism in networks, the frequency of generation of ISQ messages is reduced which result in saved bandwidth and avoid implementation complexity though CPU time is no longer a constrained resource today. When ECN is not supported in some cases, Reasonable performance of the protocols that use IP (e.g., TCP) requires an IP datagram loss rate of less than 5%[RFC 1009]. Moreover, it has been quantitatively shown in simulations [kcho-97] that less packet drops happen (only about 1-5%) of the packets are marked or dropped in a RED gateway under incipient congestion. This implies the amount of processing needed at the router is reduced and little waste of bandwidth by generation of ISQ. Fei and Jain Experimental [Page 6] Draft-fpeng-ecn Apply ECN to Wireless January 2001 So, ICMP Source Quench message (ISQ) are not generated by the intermediate congested RED router if only that router decides to mark the CE bit. ISQ are usually not generated for a packet that has already been marked previously by another router regardless of whether that packet is contributing to some congestion; however, when the router queue level mandates the dropped packet then an ISQ is sent back to the source regardless of whether the packet was marked previously or not. This function of ISQ has been supported in the routers [rfc1009] and since each router is required to provide a disable parameter, only configuration operation is taken to enable its function. 7. Support at TCP layer The requirements for the end host's reaction to ISQ are at the moment [RFC1122]. The source reacts at the transport protocol level by lowering its data throughput into the network. In TCP, upon identifying the flow causing the congestion, the sender reacts by halving both the congestion window and the slow start threshold value for that flow. The sender does not react to an ISQ message more than once per window. For multiple ECN and ISQ come back from the networks, The source only reacts the first one in a window. Upon receipt of the first ISQ or ECN at time t, it notes the packets that are outstanding at that time (sent but not yet acked) and waits until a time u when they have all been acknowledged before reacting to a new ISQ or ECN message. To prevent unnecessary reduction of window size, as notes previously, unnecessary window shield back causes low utilization of bandwidth, the measurement of the maximum window (called Wmax) experienced on a given connection. We expect this can change over time, and TCP should track these changes and modify its timeout accordingly. First TCP must measure the Wmax whenever it begins to shun down window by ISQ or ECN, we will use Mw to denote the measured Wmax. Then TCP updates a smoothed Wmax estimator using the low-pass filter Wmax <- a Wmax + (1-a) Mw Where a is a smoothing factor with a recommended value of 0.9. This smoothed Wmax is updated every time a new measurement is made. Ninety percent of each new estimate is from the previous estimate and ten percent is from the new measurement by the first receipt of ISQ or ECN in a widow cycle. Given this smoothed estimator, which changes as the Wmax changes, we recommended the threshold (Tl) to determine when packet losses should call the congestion control is set to Fei and Jain Experimental [Page 7] Draft-fpeng-ecn Apply ECN to Wireless January 2001 Tl = B Wmax, where B is a delay variance factor with a recommended value of 1.5. Since in congestion avoidance phase, the window increasing rate is linearly, only one packet is increased after a RTT, so 1.5 value of threshold is enough to avoid unnecessary window reduction by packet losses. The ISQ or ECN gives the initialized value of Wmax after the measure of the first reduction of window by either of them. If the initialization of window size is caused by packet loss controled by the threshold. The Wmax and Tl are calculated as: Wmax = a Wmax + (1-a) Tl Tl = B Wmax. Since the sender does not reduce window more than once per window, the following ISQ or ECN message do not affect any change of transmission rate until the outstanding data before the sender initiate congestion control by a packet loss upon the reach of threshold. 8. Security With the addition of ISQ messages, It becomes more security for ECN used in wireless and mobile networks. For example when some node does not support ECN mechanism, ISQ could send because the node will otherwise forced to drop IP datagrams due to congestion. Since all gateways must contain code for sending ICMP Source Quench messages in such case, the source transmission rate will be slow down even in non-ECN support environment. Also ISQ message and ECN will be lost, so it is not reliable, but since the source only shun down window once in a transmission cycle, multiple ISQs an ECNs generated at the network will not cause performance problem even with some losses of them. Moreove, the threshold set for window reduction by a packet loss though might be somehow later, it could guarantee to recover the severe congestion met by the losses of ISQ and ECN. 9. Conclusion All gateways must contain code for sending ICMP Source Quench messages when they are forced to drop IP datagrams due to congestion [RFC 1009], so only configure operation at each intermediate router in the networks is required to be taken. Without modification of ECN mechanism, we only set a threshold to delay the packt loss to Fei and Jain Experimental [Page 8] Draft-fpeng-ecn Apply ECN to Wireless January 2001 initiate congestion control and also guarantees the security of the whole system. It is very simple to implement and provides really an effective way to improve TCP performance in wireless and mobile networks for the unnecessary window reduction of losses due to transmission errors is effectively avoided. To further analyze the benefits of the whole systems, continuous simulations must execute in the future work, which contain multiple congested gateways and two way traffic with either support ECN or non-support ECN systems. Without modification of ECN mechanism, the addition of ISQ in no-support ECN systems would invariably improve TCP performance in wireless and mobile networks through preventing packet losses to initiate window reduction. It is also our future work to investigate to what extent it would contribute to improvement of TCP performance through more optimal active queue management, and a better window adaptive algorithm to suit large wide network configurations is also the requirement of study in the future. 10. References [kcho-97] Cho, K.J. ALTQ/RED Performance,http://www.csl.csl.sony.co.jp/person/kjc/red/perf.html [FeiNC] FEI, P., JIAN, M. "Overload control method for a packet-switched network", Patent Application NC 18254, June 1999. [ICCT98] FEI, P., Jian, M., etc. "TCP Performance Enhancements in Wireless and Mobile Networks", International Conference on Communication Technology (ICCT'98), Oct,1998, pp.S46-07-1:S46-07-5. [draft-kksjf] K. K. Ramakrishnan, Sally Floyd, "A proposal to add Explicit Congestion Notification (ECN) to IP", Internet Draft-kksjf-ecn-03.txt, Oct, 1998. [SF94] Sally Floyd, "TCP and Explicit Congestion Notification", Computer Communication Review, V.24 N.5, October 1994, p.10-23. [RFC1009] R. Braden, J. Postel, Requirements for Internet Gateways [draft-salim] Hadi Salim,J.,etal, A proposal for Backward ECN for the Internet Protocol (Ipv4/Ipv6), June 1998. 11. Acknowledgments We would like to appreciate Nokia cooperation for supporting this idea. We also thank Beijing University of posts and telecommunicaitons with great advocacy of our research. And we will particularly mention professor (Mrs. Cheng Shiduan),her encouragement and good advice for our work. Fei and Jain Experimental [Page 9]