Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!su-score.arpa!BILLW
From: BILLW@SU-SCORE.ARPA (William "Chops" Westfield)
Newsgroups: mod.protocols.tcp-ip
Subject: Improving TCP throughput.
Message-ID: <12155459261.8.BILLW@SU-SCORE.ARPA>
Date: Thu, 31-Oct-85 04:31:59 EST
Article-I.D.: SU-SCORE.12155459261.8.BILLW
Posted: Thu Oct 31 04:31:59 1985
Date-Received: Sat, 2-Nov-85 03:18:09 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 63
Approved: tcp-ip@ucbvax.berkeley.edu

The Tops20 TCP implementation attempts to be "sociable" by not
sending bare ACKs.  In order to do this, whenever it receives
a packet that requires an ACK, it tells itself to wait for 250
milliseconds for some data to appear that is going in the opposite
direction so that the ACK can go with it.  On something like
a telnet connection, this can essentially half the number of
packets being sent, and so it is an excellent and widely
implemented idea.

Unfortunately, Many TCP connections are essentially "one-way".
There is never going to be any data to send in the reverse
direction to piggyback the ACK on, and the system ends up
waiting when it should send and ack immediately.
Furthermore, some TCPs (including TOPS20's) calculate their
retransmission interval based on how long it takes them to receive the
ACK for a packet they have sent.  Delaying your ACK waiting for data
disturbs this calculation, as pointed out by Alan Larson on
the TOPS20 mailing list (27-Jun-85).

Now, if the time it takes the other system to fill the window
(presumably including data transmission time) is less than the
time that your system waits to send the ACK, transmission
becomes bursty, and you get serious performance degradation.
This is aggravated by fast networks and small windows.

Such was the case on Stanford Tops20 systems (which are on ethernets)
running programs using the DEC JFN interface to TCP (which advertises
a maximum 1456 byte window).  Using FTP, for example, getting a file
transfer speed of greater than 30K bps was rare.  Using a BBN/CMU FTP
(which advertises much larger windows), higher throughputs could be
achieved (up to over 300Kbps, if irratically, and in extreme cases),
which provided additional frustration.  PUP FTP regularly beat 150Kbps.

To improve upon this situation, I have implemented a concept I call
"Interactivity".  A connection is maximally interactive if a packet is
sent every time a packet is received, and minimally interactive if it
never sends any packets.  In the first case, you want to wait a bit to
try to piggyback acks on the outgoing data, but in the second case
this introduces delays, and you want to send acks immediately.
"Inverse interactivity" can be approximated by counting the number of
packets received between each one sent.  If greater than N, it is
probably a good idea to send ACKs immediately.  [Note: Immediately in
this case mean AFTER to have chosen not to avoid sending the ACK to
prevent the Silly Window Syndrome].

After performing this operation on the local tops20 systems, FTP data
rates (using the JFN interface) as high as 150kbps were seen on the
local ethernet.  As might be expected from the above discussion, little
increase in performance was seen on connections to hosts "further
away" or on connections that used very large windows.

I am CCing this message to various mailing lists besides TOPS20 since
the idea may be useful within other TCP implementations.

[The new tops20 sources (ANAUNV, TCPBBN, TCPTCP, STG) are available
 from Sierra in <6-1-monitor>, although these modules include some
 additional TCP fixes of a less general nature.  They are also on
 Score, though those sources may be in transitory states.  This
 monitor has been running on Score and Sushi since last friday
 without any apparent ill effects.]

BillW
-------