ACK and NACK, short for acknowledgement and negative acknowledgement (also written NAK), are the two signals that make data transfer reliable. When a data packet reaches its destination intact, the receiver returns an ACK. If a packet is lost or corrupted, a NACK tells the sender to resend it. This feedback loop sits at the core of reliable data protocols, from TCP on the open internet to the real-time media behind a video call.
Table of contents
- What are ACKs?
- What is a NACK?
- ACK vs NACK: what is the difference?
- Applications of ACKs and NACKs in networking
- The role of ACKs and NACKs in video conferencing
- How WebRTC handles NACKs in real-time media
- Frequently asked questions
This article looks at what ACKs and NACKs are, how they differ, and where each one is used in real-world networks.
What are ACKs?
An ACK (short for acknowledgement) is a control signal that confirms a data packet was received successfully.
It gives the sender certainty of delivery and makes it possible to handle packet loss, congestion and transmission errors, which improves bandwidth use and overall performance. These are the key roles ACKs play:
- Confirm delivery: an ACK tells the sender that a packet, or a range of packets, arrived intact.
- Pace the connection: in TCP, the rate at which ACKs return helps the sender adjust its sending speed through flow and congestion control.
- Free up resources: once a packet is acknowledged, the sender can discard its buffered copy and move on.
- Allow multiple packets in flight: cumulative and selective ACKs let several packets travel before any confirmation is needed, which keeps throughput high.
- Hint at loss: missing or duplicate ACKs are an early signal that a packet went astray, prompting retransmission.
What is a NACK?
A NACK (short for negative acknowledgement, and also written NAK) tells the sender that a receiver did not get a data packet correctly. Without it, a sender relies only on timeouts to notice a problem, whereas a NACK reports the failure straight away. Its main roles are:
- Flag loss or corruption explicitly: the receiver names the packet or frame it did not get, rather than staying silent.
- Trigger fast retransmission: the sender can resend immediately, without waiting for a timeout to expire.
- Save bandwidth: only the missing data is requested, rather than resending an entire batch.
- Support real-time media: in protocols like RTP, NACK feedback lets a sender react to loss quickly enough to protect a live stream.
ACK vs NACK: what is the difference?
The difference between an ACK and a NACK is what each one reports: an ACK confirms that data arrived correctly, while a NACK reports that data was lost or corrupted and needs resending. An ACK keeps normal data flow moving; a NACK handles the exceptions. The table below sums up how they compare.
| Feature | ACK | NACK |
|---|---|---|
| What it signals | Positive confirmation | An error or loss notice |
| State of the data | Received intact and valid | Missing, corrupted or failed a check |
| Sender's next step | Send the next packet, or clear it from the buffer | Retransmit the affected packet, or drop and requeue it |
| Role in the flow | Keeps normal transmission moving | Handles errors and triggers recovery |
Together they form a feedback loop that supports reliable communication by flagging both successes and failures.
Image source: Researchgate
Applications of ACKs and NACKs in networking
ACK and NACK messages are vital for reliable data transfer across networks. Though they work quietly in the background, they perform several key functions across different networking channels:
- ACKs confirm that TCP received data packets in the right order.
- NACKs trigger the resending of lost or corrupted packets.
- Wi-Fi uses MAC-layer acknowledgements (802.11 ACK frames) at the link layer to confirm packet delivery between a device and its access point.
- RTP-based real-time media (VoIP, video conferencing) does not use transport-level ACKs; instead, RTCP feedback messages such as NACK and PLI signal lost or damaged packets so the sender can react.
- Developers use them to check data delivery status and apply fixes.
In each case, ACKs and NACKs coordinate resilient communication across many networks and applications.
The role of ACKs and NACKs in video conferencing
Video calls rely on the same feedback principles, applied to live media. Because audio and video have to arrive in near real time, the goal is not perfect delivery of every packet but fast recovery from the losses that matter. Acknowledgement-style feedback confirms what arrived, while negative feedback flags missing or corrupted packets so the sender can respond.
When a packet is lost, a quick retransmission request can repair the stream before the gap becomes visible or audible. When loss is too heavy to recover packet by packet, the receiver asks for a new key frame instead. Together these mechanisms keep a call stable across changing network conditions, which is why they matter as much as raw latency and bandwidth.
How WebRTC handles NACKs in real-time media
Real-time video and audio don't use transport-level acknowledgements the way TCP does, because waiting for every packet to be confirmed would add too much delay. Instead, WebRTC carries media over UDP and relies on RTCP (RTP Control Protocol) feedback to manage loss. NACK is one of several tools, used alongside forward error correction and key-frame requests:
- RTCP NACK: signals that a specific media packet was lost. If the missing packet can still arrive in time to be useful, the sender retransmits it (using the RTX format); if not, it is skipped.
- PLI (Picture Loss Indication): when too much is lost to reconstruct the video, the receiver asks the sender for a fresh key frame so the picture recovers rather than freezes.
- Forward error correction (FEC): sends redundant data ahead of time so some loss can be repaired without any retransmission at all. Because a NACK adds a round trip, modern stacks combine reactive NACK with proactive FEC and apply the redundancy selectively to keep overhead down.
This selective approach is what keeps a call moving. These acknowledgement mechanisms are part of the WebRTC stack that Digital Samba's embedded video SDK manages for you. Rather than guaranteeing every packet like TCP, real-time media accepts that some loss is unavoidable and uses NACK, FEC and PLI feedback to repair only what matters, working alongside a jitter buffer to smooth out timing.
What's changing: an experimental IETF draft, RTP over QUIC (RoQ), maps RTP and RTCP onto the QUIC transport. Because QUIC already detects lost packets through gaps in its own acknowledgement frames, RTCP NACK becomes partly redundant when media runs over QUIC, a sign that the line between transport-level acknowledgements and media-level feedback is blurring. RoQ is still a draft, so classic RTP-over-UDP with RTCP NACK remains the norm today.
Conclusion
ACKs and NACKs are the quiet feedback loop behind reliable communication: acknowledgements confirm what arrived, negative acknowledgements flag what didn't, and together they decide when data needs to be resent. The balance shifts by use case: TCP leans on acknowledgements for guaranteed delivery, while real-time media uses selective NACK and FEC feedback to stay fast. For a wider view of how these choices play out in live communication, see our guide to comparing WebRTC with other real-time communication protocols.
Frequently asked questions
What is ACK?
An ACK, short for acknowledgement, is a control signal that confirms a data packet was received correctly. It is the positive counterpart to a NACK: where an ACK says the data arrived intact, a NACK reports that it did not.
What is the definition of NACK?
A NACK (negative acknowledgement) is a signal used in communication protocols indicating that a data packet was not received correctly or was corrupted. The message prompts the sender to retransmit the specific packet, improving data reliability.
What is the difference between an ACK and a NACK?
An ACK confirms that a data packet arrived correctly, while a NACK reports that a packet was lost or corrupted and needs to be resent. ACKs keep normal data flow moving, whereas NACKs handle errors and trigger retransmission. Many protocols use both together to stay reliable.
What are ACK/NACK messages?
ACK/NACK messages are control signals used in protocols to ensure reliable data transmission. An ACK confirms correct reception, while a NACK indicates an error that requires retransmission.
What does 'no ACK/NAK received' mean?
It means that neither an ACK (acknowledgement) nor a NACK was received from the receiver at that moment. It usually points to a transmission delay or a potential problem in the communication path.
Why are ACKs and NACKs important in video conferencing?
In video calls, ACK-style feedback confirms that packets were delivered, while NACKs identify lost or corrupted packets so they can be repaired quickly. This keeps audio and video smooth without adding the delay that full TCP-style retransmission would cause.
Does WebRTC use ACKs or NACKs?
WebRTC uses NACKs rather than transport-level ACKs for media. It carries audio and video over UDP and uses RTCP feedback (NACK and PLI), combined with forward error correction, to recover from loss without the delay that per-packet acknowledgement would add.
Share this
TCP vs UDP: Understanding the Two Core Transport Protocols
Understanding Network Speed, Bandwidth, and Throughput
