Congestion Control in IP/TCP Internetworks
RFC 896

Document Type RFC - Historic (January 1984; No errata)
Obsoleted by RFC 7805
Last updated 2016-04-08
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 896 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                  John Nagle
Request For Comments:  896                         6 January 1984
                    Ford Aerospace and Communications Corporation

           Congestion Control in IP/TCP Internetworks

This memo discusses some aspects of congestion control in  IP/TCP
Internetworks.   It  is intended to stimulate thought and further
discussion of this topic.   While some specific  suggestions  are
made for improved congestion  control  implementation,  this memo
does not specify any standards.


Congestion control is a recognized problem in  complex  networks.
We have discovered that the Department of Defense's Internet Pro-
tocol (IP) , a pure datagram protocol, and  Transmission  Control
Protocol  (TCP),  a transport layer protocol, when used together,
are subject to unusual congestion problems caused by interactions
between  the  transport  and  datagram layers.  In particular, IP
gateways are vulnerable to a phenomenon we call  "congestion col-
lapse",  especially when such gateways connect networks of widely
different bandwidth.  We have developed  solutions  that  prevent
congestion collapse.

These problems are not generally recognized because these  proto-
cols  are used most often on networks built on top of ARPANET IMP
technology.  ARPANET IMP based networks traditionally  have  uni-
form  bandwidth and identical switching nodes, and are sized with
substantial excess capacity.  This excess capacity, and the abil-
ity  of the IMP system to throttle the transmissions of hosts has
for most IP / TCP hosts and  networks  been  adequate  to  handle
congestion.  With the recent split of the ARPANET into two inter-
connected networks and the growth of other networks with  differ-
ing properties connected to the ARPANET, however, reliance on the
benign properties of the IMP system is no longer enough to  allow
hosts  to  communicate rapidly and reliably. Improved handling of
congestion is now  mandatory  for  successful  network  operation
under load.

Ford Aerospace and Communications  Corporation,  and  its  parent
company,  Ford  Motor  Company,  operate  the only private IP/TCP
long-haul network in existence today.  This network connects four
facilities  (one  in Michigan, two in California, and one in Eng-
land) some with extensive local networks.  This net is cross-tied
to  the  ARPANET  but  uses  its  own long-haul circuits; traffic
between Ford  facilities  flows  over  private  leased  circuits,
including  a  leased  transatlantic  satellite  connection.   All
switching nodes are pure IP datagram switches  with  no  node-to-
node  flow  control, and all hosts run software either written or
heavily modified by Ford or Ford Aerospace.  Bandwidth  of  links
in  this  network varies widely, from 1200 to 10,000,000 bits per
second.  In general, we have not been able to afford  the  luxury
of excess long-haul bandwidth that the ARPANET possesses, and our
long-haul links are heavily loaded during peak periods.   Transit
times of several seconds are thus common in our network.

RFC 896    Congestion Control in IP/TCP Internetworks      1/6/84

Because of our pure datagram orientation, heavy loading, and wide
variation  in  bandwidth,  we have had to solve problems that the
ARPANET / MILNET community is just beginning to  recognize.   Our
network is sensitive to suboptimal behavior by host TCP implemen-
tations, both on and off our own net.  We have devoted  consider-
able  effort  to examining TCP behavior under various conditions,
and have solved some widely  prevalent  problems  with  TCP.   We
present  here  two problems and their solutions.  Many TCP imple-
mentations have these problems; if throughput is worse through an
ARPANET  /  MILNET  gateway  for  a given TCP implementation than
throughput across a single net, there is a high probability  that
the TCP implementation has one or both of these problems.

                       Congestion collapse

Before we proceed with a discussion of the two specific  problems
and  their  solutions,  a  description of what happens when these
problems are not addressed is in order.  In heavily  loaded  pure
datagram  networks  with  end to end retransmission, as switching
nodes become congested, the  round  trip  time  through  the  net
increases  and  the  count of datagrams in transit within the net
also increases.  This is normal behavior under load.  As long  as
there is only one copy of each datagram in transit, congestion is
under  control.   Once  retransmission  of  datagrams   not   yet
delivered begins, there is potential for serious trouble.

Host TCP  implementations  are  expected  to  retransmit  packets
several times at increasing time intervals until some upper limit
on the retransmit interval is reached.  Normally, this  mechanism
is  enough to prevent serious congestion problems.  Even with the
better adaptive host retransmission algorithms, though, a  sudden
Show full document text