ACKs and NACKs Explained: The Feedback Loop Behind Reliable Data

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

1. What are ACKs?
2. What is a NACK?
3. ACK vs NACK: what is the difference?
4. Applications of ACKs and NACKs in networking
5. The role of ACKs and NACKs in video conferencing
6. How WebRTC handles NACKs in real-time media
7. 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?

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:

• 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, 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:

• 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?

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:

• ACKs confirm successful data reception, while NACKs indicate issues requiring retransmission.
• ACKs confirm packets were received successfully, whereas NACKs prompt the resending of packets that had problems.
• ACKs verify that everything worked; NACKs detect failures or missing packets.
• ACKs show what went right in the transmission; NACKs reveal what went wrong.
• ACKs maintain normal data flow; NACKs handle exceptions and ensure corrections.

Together, they form a feedback loop that supports reliable communication by identifying 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. 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.

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 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 ACK?

An ACK, short for acknowledgement, is a control signal that confirms a data packet was received correctly.

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.