tcp-ip@ucbvax.ARPA (07/31/85)
From: Lixia Zhang <Lixia@MIT-XX.ARPA> Could someone tell me if there is/are TCP imlementations that withhold acknowledgment packets? And if so, are they the majority? and how do they do it? (I've read rfc813 by Dave Clark on that topic, but I'd like to know whether/how it is implemented.) Many thanks. Lixia -------
tcp-ip@ucbvax.ARPA (08/01/85)
From: David C. Plummer in disguise <DCP@SCRC-QUABBIN.ARPA>
Date: Tue 30 Jul 85 10:57:15-EDT
From: Lixia Zhang <Lixia@MIT-XX.ARPA>
Could someone tell me if there is/are TCP imlementations that withhold
acknowledgment packets?
And if so, are they the majority? and how do they do it?
(I've read rfc813 by Dave Clark on that topic, but I'd like to know
whether/how it is implemented.)
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.
If by withholding acks you are thinking about avoiding silly-window
syndrome, that is NOT withholding acks, that is withholding window
enlargments. Our implementation does that too. I think just about
every implementation does these days. It isn't hard. (It's a bit
easier if you deal with limit sequence numbers instead of base+count,
since limits stay constant while base increases and count decreases, and
just makes my brain hurt making sure they increase/decrease by the same
amount...)tcp-ip@ucbvax.ARPA (08/05/85)
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?
Lixia
-------tcp-ip@ucbvax.ARPA (08/06/85)
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.tcp-ip@ucbvax.ARPA (08/06/85)
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 -------
tcp-ip@ucbvax.ARPA (08/06/85)
From: MILLS@USC-ISID.ARPA In response to the message sent Sun 4 Aug 85 20:13:23-EDT from Lixia@MIT-XX.ARPA Lixia, Further to my previous message, the fuzzy ones do in fact produce fewer acks than received segments on average, far fewer in the case of tinygram (interactive) traffic due to the 500-millisecond left-window edge delay. In typical character-at-a-time traffic with TELNET, twinkling on the keys results in no unpiggybacked acks at all - just tinygrams. The send policy and ack policy then result in a packet exchange between the user and server every 500 milliseconds with whatever queues up in the interval in the segment. Watch a Unix, TOPS-20 or especially a PCIP for somewhat less efficient behavior (!). Dave -------
tcp-ip@ucbvax.ARPA (08/06/85)
From: Ken Harrenstien <KLH@SRI-NIC.ARPA> For what it's worth, the ITS implementation of TCP/IP uses an ACK strategy almost identical to that described by DCP and Mills. The timeout is likewise at most 1/2 second, although there is no attempt to be precise about it. I guess I am surprised to hear that there are systems which do not work this way. -------