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.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!daemon
From: tcp-ip@ucbvax.ARPA
Newsgroups: fa.tcp-ip
Subject: Re: Withholding Acks
Message-ID: <9685@ucbvax.ARPA>
Date: Mon, 5-Aug-85 18:58:33 EDT
Article-I.D.: ucbvax.9685
Posted: Mon Aug  5 18:58:33 1985
Date-Received: Tue, 6-Aug-85 12:34:34 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 30

From: MILLS@USC-ISID.ARPA

In response to the message sent  Tue 30 Jul 85 10:57:15-EDT from Lixia@MIT-XX.ARPA

Lixia,

We know this as the "ack policy." This interacts with the "send policy"
(see MIL-STD-1778) in interesting ways, as we have found when experimenting
with the send policy first suggested by John Nagle and previously reported to
the tcp-ip list. Specifically, our fuzzballs transmit an ack in response
to a tcp segment:

1. Immediately if the segment is entirely outside the receive window.

2. Immediately if the number of octets delivered to the user (sequence
   advanced at the right-window edge) is at least a magic number (currently
   the MSS of the connection) since the last ack.

3. After a short magic-number delay (currently 500 milliseconds) since the
   last segment that advanced the left-window edge with no intervening ack.

The intent is to withold acks for short (interactive) segments to encourage
piggybacking, both for acks and echoes, while supporting maximum
throughput for large segments and low-delay nets. I am not entirely happy
with the above, since segments that are a weenie bit shorter than MSS get
poor treatment in both the send and ack policies. An ingenious adaptive
strategy might be considered for trial.

Dave
-------