Network Working Group M. Handley
Request for Comments: 2861 J. Padhye
Category: Experimental S. Floyd
ACIRI
June 2000
TCP Congestion Window Validation
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
TCP's congestion window controls the number of packets a TCP flow may
have in the network at any time. However, long periods when the
sender is idle or application-limited can lead to the invalidation of
the congestion window, in that the congestion window no longer
reflects current information about the state of the network. This
document describes a simple modification to TCP's congestion control
algorithms to decay the congestion window cwnd after the transition
from a sufficiently-long application-limited period, while using the
slow-start threshold ssthresh to save information about the previous
value of the congestion window.
An invalid congestion window also results when the congestion window
is increased (i.e., in TCP's slow-start or congestion avoidance
phases) during application-limited periods, when the previous value
of the congestion window might never have been fully utilized. We
propose that the TCP sender should not increase the congestion window
when the TCP sender has been application-limited (and therefore has
not fully used the current congestion window). We have explored
these algorithms both with simulations and with experiments from an
implementation in FreeBSD.
1. Conventions and Acronyms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [B97].
Handley, et al. Experimental [Page 1]RFC 2861 TCP Congestion Window Validation June 20002. Introduction
TCP's congestion window controls the number of packets a TCP flow may
have in the network at any time. The congestion window is set using
an Additive-Increase, Multiplicative-Decrease (AIMD) mechanism that
probes for available bandwidth, dynamically adapting to changing
network conditions. This AIMD mechanism works well when the sender
continually has data to send, as is typically the case for TCP used
for bulk-data transfer. In contrast, for TCP used with telnet
applications, the data sender often has little or no data to send,
and the sending rate is often determined by the rate at which data is
generated by the user. With the advent of the web, including
developments such as TCP senders with dynamically-created data and
HTTP 1.1 with persistent-connection TCP, the interaction between
application-limited periods (when the sender sends less than is
allowed by the congestion or receiver windows) and network-limited
periods (when the sender is limited by the TCP window) becomes
increasingly important. More precisely, we define a network-limited
period as any period when the sender is sending a full window of
data.
Long periods when the sender is application-limited can lead to the
invalidation of the congestion window. During periods when the TCP
sender is network-limited, the value of the congestion window is
repeatedly "revalidated" by the successful transmission of a window
of data without loss. When the TCP sender is network-limited, there
is an incoming stream of acknowledgements that "clocks out" new data,
giving concrete evidence of recent available bandwidth in the
network. In contrast, during periods when the TCP sender is
application-limited, the estimate of available capacity represented
by the congestion window may become steadily less accurate over time.
In particular, capacity that had once been used by the network-
limited connection might now be used by other traffic.
Current TCP implementations have a range of behaviors for starting up
after an idle period. Some current TCP implementations slow-start
after an idle period longer than the RTO estimate, as suggested in
[RFC2581] and in the appendix of [VJ88], while other implementations
don't reduce their congestion window after an idle period. RFC 2581