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!usc-isid.arpa!MILLS
From: MILLS@USC-ISID.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: Improving TCP throughput.
Message-ID: <8511010543.AA11097@ucb-vax.berkeley.edu>
Date: Fri, 1-Nov-85 00:31:27 EST
Article-I.D.: ucb-vax.8511010543.AA11097
Posted: Fri Nov  1 00:31:27 1985
Date-Received: Sat, 2-Nov-85 07:21:39 EST
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 24
Approved: tcp-ip@ucbvax.berkeley.edu

In response to the message sent  Thu 31 Oct 85 01:31:59-PST from BILLW@SU-SCORE.ARPA

Bill,

It's refreshing to see that somebody is still brave enough to keep hacking
at TCP trying to improve performance. We have seem some awful broken
things wandering by our gateway, some of which caused massive congestion
due imappropriate choices of retransmission timeouts, packetization, etc.

Our darling fuzzballs were taught a very similar trick some time back for
the same reason - to improve throughput on low-delay nets while sustaining
good packetization efficiency on long-delay ones. However, we took a slightly
different approach. If the left window edge moves an ACK will be guaranteed
after no more than a nominal delay (about the same as yours). If the right
window edge moves more than MSS octets since the last ACK, an ACK is
forced immediately. Thus, high-volume traffic with max-size packets is
not delayed, while interactive traffic with tinygrams is delayed for
piggybacking opportunities. Using the Nagle Algorithm together with this
technique, a typist can twinkle on a keyboard with a TOPS-20 or fuzzball
(but not a 4.2) and result in one segment flipping end-for-end picking
up data, remote-echoes and ACKs as it flips. The gateways love it.

Dave
-------