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 -------