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: <9680@ucbvax.ARPA>
Date: Mon, 5-Aug-85 17:54:00 EDT
Article-I.D.: ucbvax.9680
Posted: Mon Aug  5 17:54:00 1985
Date-Received: Tue, 6-Aug-85 12:33:13 EDT
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 51

From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>

    Date: Sun 4 Aug 85 20:13:23-EDT
    From: Lixia Zhang <Lixia@MIT-XX.ARPA>

    Dave,

    Thanks for your msg.  From yours and other replies I got, it seems that I
    didn't make the inquiry clear.  By withholding acks I mean WITHHOLDING
    ACKs, i.e. do not acknowledge every incoming data segment so that the total
    number of acks sent out will be smaller that the number of incoming data
    packets.

    From your msg,
	  "The Symbolics implementation for 3600s sets a flag in a connection
	  saying "send an ack when you get a chance."  Therefore, we do withhold
	  ACKs in a sense."
    Do you mean the acks are polled by the sender only (i.e. the receiving end
    does not ack until it sees a flag) ?

    Withholding window enlargement may have an effect, but surely the two
    are not the same. I'm more concerned with the internet data traffic. I
    don't know how much percentage of the total is due to the acknowledgment
    packets.  For telnet connections it is possible to do piggybacking (how
    well this is done is still up to the implementation), but for FTP or mail
    data basically flow in one direction only, do they generate as many acks as
    data pkts or substantially less?

Here's a more detailed description of how we do it.

When new data arrives, an flag is set which says "this connection has
data that has not been acked."

When an ack is sent for any reason, the flag is cleared.

There is a timer (currently set at .1 seconds) that will cause the ack
to be sent if the flag is set.  .1 seconds was choosen to be long enough
to gather other data and ACK an entire group and short enough so the
other wide won't retransmit a longer packet.

Acks are also sent with window enlargments (per silly window avoidance).
Under normal high traffic conditions, this is the normal case.  Data is
normally received and gobbled and the window is enlarged faster than the
.1 second timeout.

I believe an ack is also sent when the input queue becomes empty.

Under this strategy, with 1500 byte Ethernet packets, 20Kbyte window, we
normally see 1 outgoing ACK (very small packets) for every 3 incoming
(large) segments.  We also see very few retransmissions because of
timeouts.