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!cbosgd!ucbvax!tcp-ip
From: karn@MOUTON.ARPA (Phil R. Karn at mouton.ARPA)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: TCP Send buffer constraints destroy datarate
Message-ID: <8601140659.AA19188@mouton.ARPA>
Date: Tue, 14-Jan-86 01:59:12 EST
Article-I.D.: mouton.8601140659.AA19188
Posted: Tue Jan 14 01:59:12 1986
Date-Received: Wed, 15-Jan-86 01:18:36 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 21
Approved: tcp-ip@sri-nic.arpa

Delaying acknowledgements with timers has always bothered me.  Either the
application will send something in reply almost immediately (e.g., Telnet
echoing) or it will take so long that the acknowledgment timer will expire
with nothing to send, increasing the effective round trip time and limiting
throughput when the windows are small.

In an upcall environment, it would seem better to just note the fact that an
ack is owed and upcall the user, giving him a chance to send some data. Once
the user returns, you immediately invoke the tcp output routine which sends
the ack plus reply data, if any.  This avoids having to set a short timer,
which is often hard to do efficiently in an operating system environment.
Of course, the user cannot be permitted to block.

Another approach is to look at the incoming PSH bit. Since PSH from the
remote TCP usually means "I think my client doesn't have any more data to
send for a while", you could start the acknowledgement delay timer only if
PSH is clear; otherwise you would immediately return an ACK. This would
have the additional advantage of allowing you to acknowledge a burst of
segments with a single response.

Phil Karn