--PmA2V3Z32TCmWXqI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 05, 2005 at 05:28:17PM -0700, Jonathan Stone wrote:
>=20
> In message <20050805222625.GA9074@netbsd.org>,
> Bill Studenmund writes:
>=20
> >On Sun, Jul 31, 2005 at 10:35:19PM +0900, YAMAMOTO Takashi wrote:
> [...]
>=20
> >> 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.
>=20
> 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:

I have traces around somewhere which I have stared at with Ethereal.

The pattern I see is a flow of writes to the NetBSD box, perhaps with ACKs=
=20
interspursed (I don't actually remember either way). Then I see a spew of=
=20
ACKs with no other activity. Say about 12 in a row.

> a)  ACKing every other in-order segment as the segments are received
>=20
> b) sending non-piggybacked window updates as the application reads
> data

I expect this is what I'm seeing. Well, the part of what I'm seeing that I
dislike. I however have not figured out where this happens in the code.
:-)

> 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.

Ok, I'll try this when I get a chance.

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

Small pieces. Well, small and large chunks.

> >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.
>=20
> 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.
>=20
> 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).

I think it could be quite useful. However the thing that has me most
stumped is how to end the delay. What I'd like is something that knew if
the app was still reading, and kept processing rather than send the ACK
(delay the ACK as we will have another window update in just a little
bit).  Well, if the window changed more than a set amount, send a window
update anyway.

I however have no idea how to reasonably implement knowing "if the app was=
=20
still reading". Thus the idea is still a pipe dream. :-)

In my mind, a delay of even a tick (10 ms) is probably too long. The=20
environment I'm looking at can transmit the TCP window about 5 times in a=
=20
tick. So that won't work.

> >The problem is that to delay sending them means we need some sort of
> >timeout.
>=20
> 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.

Uhm, I never suggested delaying receipt ACKs. Or I never meant to.

My thoughts are solely around exclusive window updates. Or I think they=20
are. :-)

It could be I should just leave TCP alone and do something different with=
=20
my application.

> Salt the above with smiley emoticons to your taste.
>=20
> (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)

No idea.

Take care,

Bill

--PmA2V3Z32TCmWXqI
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFC9BBEWz+3JHUci9cRAiS4AJ9Ufip91sZRVk8tHnIEPjCXRvnLQwCfYoth
9obi2CDJiMzavyHwjqRQW+c=
=yi4U
-----END PGP SIGNATURE-----

--PmA2V3Z32TCmWXqI--