ACKs and NACKs, short for acknowledgements and negative acknowledgements, are central to making data transfer reliable. When data packets reach their destination, the receiver sends an ACK (acknowledgement). If packets are lost or corrupted, a NACK (negative acknowledgement) is sent, prompting the sender to retransmit the missing packets. This feedback loop sits at the core of many reliable data protocols.
Table of contents
This article looks at what ACKs and NACKs are, how they differ, and where each one is used in real-world networks.
ACKs, meaning acknowledgements, are control signals used in communication protocols to confirm that a data packet was received successfully.
They provide certainty of delivery and make it possible to handle issues such as packet loss, congestion, and transmission errors, improving bandwidth use and overall performance. These are the key roles ACKs play:
A NACK, meaning negative acknowledgement, indicates that a receiver did not get a data packet correctly. Without NACKs, senders rely only on timeouts to detect packet problems, whereas a NACK reports the failure straight away. Its main roles are:
ACKs and NACKs are both important for reliable data transmission. ACKs confirm that data was received correctly, while NACKs report errors or problems. The main differences are:
Together, they form a feedback loop that supports reliable communication by identifying both successes and failures.
Image source: Researchgate
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:
In each case, ACKs and NACKs coordinate resilient communication across many networks and applications.
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.
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:
This selective approach is what keeps a call moving. 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 in 2026: an emerging IETF specification, RTP over QUIC (RoQ), maps RTP and RTCP onto the QUIC transport. Because QUIC already detects lost packets through gaps in its own ACK 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.
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.
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.
An ACK, short for acknowledgement, is a control signal that confirms a data packet was received correctly.
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.
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.
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.
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.