NACK stands for Negative Acknowledgement. It is the message a media receiver sends back to the sender to say that a specific RTP packet never arrived, and to ask for it to be retransmitted.
In plain terms: a NACK is how a receiver says "I did not get that packet, send it again".
NACK is one of the primary error-recovery tools in real-time media protocols, used alongside FEC to handle packet loss. The message is sent over RTCP to the sender of the media, which then decides whether to retransmit based on the packet's availability in its cache and on whether the retransmission would still be useful by the time it arrives.
What is NACK and how does it work?
The mechanism of NACK is straightforward yet crucial for maintaining the quality of the communication link. When a receiver detects the absence of a specific packet, e.g. by observing a gap in the RTP sequence number of the packets received, it forms a NACK message with a list of sequence numbers it considered missing and would like to have retransmitted.
This message is then transmitted over RTCP to the sender of the media. The responsibility now lies on the sender to evaluate the request for retransmission. In WebRTC, the retransmitted packets are usually carried on a separate RTX stream rather than in the original one.
ACK vs NACK
An ACK (Acknowledgement) confirms what did arrive. A NACK reports what did not. Protocols like TCP acknowledge the data that arrives, so the sender infers loss from the acknowledgements it does not get back. Real-time media takes the opposite approach: acknowledging every packet would be a lot of feedback traffic for very little value, so the receiver stays quiet until something goes missing and only then sends a NACK. That keeps the feedback channel small and the reaction fast, which is what matters when the media has a deadline.
Deciding whether to retransmit
Upon receiving a NACK message, the sender has to make a calculated decision regarding the retransmission of the lost packets.
This decision hinges on two primary factors:
- The availability of the packet in its cache
- The estimated usefulness of the retransmission
The sender evaluates whether the retransmitted packet, once received, will still hold value for the ongoing communication. For example, the lost packet could be part of a video frame that is discardable on the receiver due to temporal scalability. If the sender decides the packet is most likely not important, it won't retransmit it.
This evaluation minimizes network bandwidth waste by preventing the retransmission of packets that would arrive too late to be useful for decoding and playback, such as those belonging to frames that have already been superseded or discarded by the receiver.
Why NACK matters in WebRTC
The implementation of NACK in WebRTC directly impacts the quality and reliability of real-time communication. It is focused on video streams where the encoding of frames depends on receiving the complete sequence of frames and a lot less on audio streams where codecs such as Opus deal well with the loss of a single frame.
By providing a mechanism to request for lost packet retransmission, NACK plays a vital role in mitigating the effects of packet loss, thereby enhancing the overall user experience in a WebRTC environment. When too much is missing for retransmission to help, or when the retransmission would arrive too late, the receiver falls back on asking for a fresh keyframe with a PLI message instead.
