In message <20050805222625.GA9074@netbsd.org>,
Bill Studenmund writes:

>
>On Sun, Jul 31, 2005 at 10:35:19PM +0900, YAMAMOTO Takashi wrote:
[...]

>> a question is: what's a rationale of this?
>> it looks too frequent to me, given that
>> "an ack for at least every second segment" is
>> already achieved by TCP_SETUP_ACK.
>
>I'm not sure. I however would LOVE it if we or someone could answer this
>question. I am interested in near-unidirectional bulk transfers, and am
>very puzzled by the amount of ACKs we send.

Do you have packet traces?  Have you tried using tcptrace to
understand them?  Without a packet trace to examine, it's hard to be
sure, but absent that data, I'd guess that TCP is doing both of:

a)  ACKing every other in-order segment as the segments are received

b) sending non-piggybacked window updates as the application reads
data

The easy way to check is to look at the yellow/orange line in tcptrace
TSG graphs. If that line goes up when the green line stays flat,
you're seeing window updates.

Do the apps in question issue read()s in big fat chunks, or in small
pieces?



>I think we send an ack each time userland reads something, in the hopes of
>keeping the window as open as possible. That's kinda good. However it'd be
>nice to meter them somehow.

I'd guess not; what you describe sounds sounds more like our TCP is
sending window updates to its TCP peer, triggered by an application
removing (reading) data from the local TCP receive buffer.

Given the uncertainties in TCP RTT estimation, and that you want
BW*RTT data in flight, metering ACKs sounds to me like it'd make an
interesting research project (albeit one of dubious value to the TCP
research community).


>The problem is that to delay sending them means we need some sort of
>timeout.

Worse than that; I'd expect beleivers in ACK clocking will complain
fiercely if you delay ACKs for in-order received data, until the
occurrence of unpredictable (and, to network-level TCP dynamics,
largely "irrelevant") events, such as an application reading data.

Salt the above with smiley emoticons to your taste.

(Wan't it Jason who opined some 8 years back that perhaps our TCP
should send an ACK for *every* received segment? Or am I misremembering)