1. Overview
Acknowledgment (ACK) signals are an important part of the protocols used in data networks and telecommunications. They provide the basis for reliable communication. There are two types of ACKs: positive and negative.
In this tutorial, we’ll discuss positive and negative ACKs.
2. Positive ACKs
Positive ACKs, or simply ACKs, are an important component of reliable communication between a sender and a receiver. An ACK is a positive response from the receiver to the sender to signal that a packet of data was received successfully.
When the sender doesn’t receive an ACK from the receiver for a packet sent in a specific timeout period, it resends the same packet.
ACKs are suitable for reliable point-to-point or unicast traffic. TCP is a typical example of such a protocol using ACKs to provide reliable communication between a sender and receiver. Therefore, we’ll focus on TCP in our examples.
We’ll divide ACKs into three categories.
2.1. Delayed ACKs
The receiver doesn’t need to send an ACK for every segment it receives. For example, if there’s still space in the receiver’s buffer after receiving a segment from the network, it may prefer to wait till it gets a new segment that fills its buffer. It empties its buffer by delivering the buffered segments to the higher levels of the network stack. Then, it sends an ACK containing the next expected sequence number and the window size to the sender.
Another case for delaying ACKs is interactive data flow using TCP. Telnet is an example of interactive data flow. We have the following traffic in a typical telnet session:
- The telnet client, which initiates the telnet session, sends a keystroke to the telnet server
- The server acknowledges the keystroke
- After the server processes the message, it sends the echo of the keystroke back to the client
- The client acknowledges the echo
Each of these steps corresponds to a TCP segment. For example, the second segment, i.e., the ACK of the keystroke, consists of only a TCP header with no data. The visual description of these steps is below:
However, instead of sending an ACK immediately, the server may delay it because data can be sent in the same direction as the ACK in a short time interval. After the server processes the keystroke, TCP can merge the second and third segments and transmit the ACK together with the echo. This is also known as piggybacking.
TCP implementations may delay ACKs and window updates for up to 500 msec.
2.2. Cumulative ACKs
Thanks to TCP’s sliding window protocol, the sender can send multiple segments before it stops and waits for an ACK. Consequently, this mechanism provides faster data transfer as the sender doesn’t have to wait for an ACK for each segment it transmits but waits for a cumulative segment for the segments it has sent.
For example, if the sender sends ten segments without waiting for an ACK, the receiver may send a single cumulative ACK for the ten segments. However, the receiver may also send an ACK, for instance for the first six segments, depending on the emptiness of its receive buffers.
Cumulative ACKs are useful in bulk data flows like FTP, which uses TCP under the hood.
2.3. Selective ACKs
Sending cumulative ACKs may not always be efficient. For example, let’s consider the case where the sender sends ten segments, and the receiver receives all the segments except the third one since it’s lost during transmission. The receiver can only send a cumulative ACK for the first and second segments using the TCP ACK number, i.e., it reports that it waits for the third segment.
However, it can’t tell the sender that it has received the fourth and following segments using cumulative ACKs. Therefore, the sender eventually resends the third and following segments again, although only the third segment was lost.
Selective ACKs (SACKs) solve this problem. While establishing the TCP connection, the sender and the receiver set the optional SACK Permitted field in the TCP header to indicate they can use SACKs.
If the receiver doesn’t receive the third segment of the ten segments sent by the sender, then it sends a cumulative ACK for the first and second segments as before. Additionally, it sends the range of the other successfully received segments in the SACK option of the TCP header. In our case, it specifies the fourth and tenth segments as the start and end of the range in the SACK option. Consequently, the sender can understand that the third segment is missing.
When multiple gaps are present in the received packets, TCP can send up to four ranges in the SACK option.
3. Negative ACKs
IP multicast uses UDP as the transport protocol. Since IP multicast and UDP are unreliable, i.e., packets might be lost and can’t be recovered, they’re used in streaming video and audio, where occasional packet losses don’t cause a problem.
If we need to ensure reliable multicast communication when there are many receivers, sending ACKs for every received packet or group of packets might cause ACK implosions to overwhelm the sender. Therefore, using ACKs may not be an appropriate solution to provide reliable multicast communication.
However, it’s possible to provide reliable multicast communication using NACKs instead of ACKs. Receivers send a NACK only when they detect a missing packet. The sender needs to sign each packet it sends with a sequence number, perhaps in the presentation layer.
When a receiver detects a missing packet, it may send the NACK to the sender as a unicast message together with the sequence number of the missing packet. After receiving the NACK, the sender might resend the previously lost packet as a unicast message to the receiver. Another option is to send the message using multicast as other receivers might have lost the same packet due to a transient network problem.
Another alternative for the receiver that detects a missing packet is to send the NACK as a multicast message instead of a unicast message. In this case, any other receiver that has received the message can send it as a multicast message. We may introduce a random delay before sending a NACK to prevent NACK implosions and unnecessary network traffic.
Most distributed computing platforms support reliable communication using NACKs. For example, the Data Distribution Service (DDS) uses the Real-time Publish-Subscribe (RTPS) protocol under the hood. A Reader can inform a Writer about the sequence numbers missing using NACKs in RTPS.
4. Conclusion
In this article, we discussed positive and negative ACKs. Both provide a reliable communication mechanism.
Firstly, we examined positive ACKs. We learned that positive ACKs are more suitable for unicast traffic like TCP. We classified positive ACKs into three groups, namely delayed, cumulative, and selective ACKs. A receiver can delay an ACK in order to send the ACK together with data. This is particularly useful in interactive data flow like telnet. A sender can send several segments without waiting for an ACK for each segment. The receiver can send a single cumulative ACK for the received segments.
Selective ACKs are useful when some of the segments in between are lost. The receiver can report the lost gaps to the sender using the SACK option in the TCP header.
Finally, we examined NACKs. We learned that NACKs are more suitable for reliable multicast communication. A receiver sends a NACK only when it can’t receive a packet.