Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: TCP Timer
Message-ID: <8129@ucbvax.ARPA>
Date: Thu, 13-Jun-85 13:29:17 EDT
Article-I.D.: ucbvax.8129
Posted: Thu Jun 13 13:29:17 1985
Date-Received: Fri, 14-Jun-85 04:41:23 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 58

From: CLYNN@BBNA.ARPA

Lixia,
	Working with the DARPA Protocol Suite on TOPS20s has lead to
the same conclusions that Dave has mentioned.  I think that Geof's
statement that "performance could be drastically affected" is weak - it
is drastically affected, especially when the retransmitter does not
have a very good round-trip-time algorithm.

	A refinement of only sending the "first packet" in the queue
is to only retransmit one packet - the "first packet" plus as much
additional data from other packets as will fit into a maximum sized
segment (repacketization).  This is effective in reducing character
per round-trip-time echoing in telnet applications (dribble echo)
since most original packets have few data octets and most (if not all)
of the outstanding data will fit into a maximum sized segment.  As Geof
points out, it does present problems if the packets to be retransmitted
are all full size; more below.

	The statement that when a packet is retransmitted, it plus all
the others that made it the first time will be acked is true some of
the time.  It fails when the receiver is packet-event driven, i.e.,
the receiver responds to each packet it processes.  In such a case it
will ack the retransmitted packet, then proceed to reassemble the
other packets from its reassembly queue, acking each one in turn.  The
sending host then sees several acks arriving instead of one.  If it has
set a timer for each packet in the retransimssion queue, the timer for
the second packet has probably already gone off.  Consequently, when
the ack for the packet which was retransmitted arrives, the second
packet becomes the first and is retransmitted - frequently just before
the ack arrives.

	Retransmission of everything which is outstanding can make
performance worse, due to the interaction of factors, e.g., window
size, available data, round-trip-time algorithm, gateways, etc.  A
large window with lots of data causes, for example, the x
implementation on the x, to send as many packets as fast as possible.
Many gateways cannot handle the large burst of packets, so discard a
few, pass a few, drop a few more, etc.  When the retransmission timer
goes off, everything in the queue is retransmitted - some packets get
through and a few more are dropped.  The lost packets seem to make the
round-trip-time estimate grow very large, so throughput goes way down
(wait a minute, send a flood, wait a minute ...).  If the recieving
host can figure out what is happening it can "discourage" such
behavior by using the window to limit the number of packets so that
the gateway will not be swamped (source quench doesn't seem to be well
enough defined and widely enough implemented to be effective).  In
practice, closing the window to just cover the gap of lost packets and
delaying the ack until the reassembler has to stop seems to help a
lot.  (Of course, the sending host should attempt to limit its rate of
packet generation - delays between packets (or fragments in a gateway),
maximum number of outstanding packets (possibly a function of what had
to be retransmitted), etc.)

	Add TOPS20s to your survey under the "single timer,
retransmits a single repacketized packet, with delayed ack" column.

Charlie