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!cbosgd!ucbvax!tcp-ip
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: Floods of tinygrams from telnet hosts
Message-ID: <7763@ucbvax.ARPA>
Date: Tue, 4-Jun-85 01:52:22 EDT
Article-I.D.: ucbvax.7763
Posted: Tue Jun  4 01:52:22 1985
Date-Received: Thu, 6-Jun-85 01:42:55 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 37

From: imagen!geof@BERKELEY


The worst offenders of the tinygram explosions seen by Dave Mills are
probably Unix systems running server telnet.  Every Unix TCP
implementation I've seen (save one) has the characteristic that packets
are sent whenever a unix WRITE(I) call is made.  In many applications,
this happens once per character.  Unix also makes it very difficult to
heuristically combine this flood of characters into larger packets
(except on retransmission), through a combination of factors including
interfaces that were designed for blocking system calls, and incredibly
poor resolution of application-level timers.

The one implementation I've seen that solves this problem uses the
algorithm that John Nagle of Ford Aerospace developed.  My
understanding of it is (John, please correct any innaccuracies) that a
TCP implementation will emit a new packet only under the following
situations:
	- Its internal buffers are full (i.e., it is ready to send a
	  full sized packet)
	- All outstanding data it has sent has been acknowledged by the
	  remote TCP.
When communicating over a local net, this algorithm works fine for
telnet, since the intercharacter time is typically less than the
connection round trip time.  Whenever the intercharacter time of the TCP
client becomes greater than the round trip time, the algorithm
naturally divides the data to be sent into equally sized packets, based
on the ratio of intercharacter time to round trip time.

In the case of FTP-like connections, the algorithm degenerates into the
current behavior, since the internal buffers are always full.

Will someone please implement this on a 4.2 unix?  Then maybe I'll be
able to get decent response from APL when I telnet into the 4.2 machine
on the local ethernet!

- Geof