Path: utzoo!mnetor!uunet!husc6!necntc!ima!think!barmar
From: barmar@think.COM (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Implicit acks in TCP?
Message-ID: <17527@think.UUCP>
Date: 4 Mar 88 20:38:11 GMT
References: <17229@watmath.waterloo.edu>
Sender: usenet@think.UUCP
Reply-To: barmar@fafnir.think.com.UUCP (Barry Margolin)
Distribution: comp
Organization: Thinking Machines Corporation, Cambridge, MA
Lines: 33
Keywords: TCP, Implicit ack

In article <17229@watmath.waterloo.edu> jwkhong@grand.waterloo.edu (James W. Hong) writes:
>I wonder if someone could clarify a point for me regarding acks in
>TCP.  Are implicit acks allowed in TCP?  What I mean by an implicit
>ack is that each request or response message serves as an implicit
>ack for the previous response or reqeust message from that client,
>respectively.

Your question indicates that you misunderstand TCP.  TCP does not have
any notion of "request" and "response" messages; some higher-level
protocols, such as RPC (Remote Procedure Call), may have them, though.
TCP implements a reliable bidirectional stream of octets on top of a
lower-level unreliable datagram facility (generally IP).  TCP doesn't
require that every transmission in one direction be followed by a
transmission in the other direction.

Every TCP datagram includes an explicit ack, so there can be no
"implicit" acknowledgements.  However, for ease of implementation,
most implementations send an empty acknowledgement datagram as soon as
they receive a datagram.  While they could wait and try to piggy-back
it on the next outgoing datagram to that host, they would also have to
set a timer so that an empty ack could be sent out sooner if no
outgoing data is sent soon.  For applications where a large amount of
data is going one way and very little goes the other way (e.g. mail
transfer) this could reduce throughput, because acks would not come as
soon as the receiver was actually ready to receive more.  And if the
acks are sent too late, the sender might end up retransmitting packets
that were actually received intact.

Barry Margolin
Thinking Machines Corp.

barmar@think.com
uunet!think!barmar