Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!pasteur!ucbvax!AMES-NAS.ARPA!rfox
From: rfox@AMES-NAS.ARPA (Richard Fox)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  Implicit acks in TCP?
Message-ID: <8803032208.AA11552@ames-nas.arpa>
Date: 3 Mar 88 22:08:20 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 17

TCP is a byte stream protocol. This means that it works based on bytes
being sent, not packets per se. Thus, you'll notice that the ACK field
is acking bytes not packets sent. To ack each byte individually would
take forever, so the ack is stating which byte it expects to receive
next ( or as you put it, it is implicity ACK'ing all data up to a certain
point). Since each packet of data contains an ACK, if you notice that
you are sending 4 packets instead of 2, where 2 would suffice if ACKS
are piggybacked, then it is your implementation adding the extra
packets, not the protocol. 

I believe the problem you stated with your implementation is happening
because you have delayed acking turned off. This means as soon as you
know you can ack something received do so, then go ahead and process
the request ( ie: get and send the data).

Hope this helps some,
rich