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]
