QUIC’s "fast retransmit" isn’t really a distinct mechanism; it’s a consequence of its more granular acknowledgement system.
Let’s watch QUIC recover from a lost packet. Imagine Client A sending a stream of data to Server B. QUIC, unlike TCP, doesn’t send data in one big chunk with a single sequence number. Instead, it uses Packets and Frames. Each packet can contain multiple frames, and frames represent actual data, acknowledgements, or control information.
Here’s a simplified view of what Client A might send:
Packet 1 (Packet Number 100):
- Frame 1: STREAM_DATA, Offset 0, Length 1000
- Frame 2: STREAM_DATA, Offset 1000, Length 1000
Server B receives these. Its QUIC implementation needs to acknowledge the data. Crucially, QUIC acknowledgements are also packetized and refer to packet numbers.
Packet B1 (sent by Server B):
- Frame 1: ACK, Lowest Unacked: 100, Max Unacked: 100, Acknowledge Packet 100
- Range 1: Start 100, End 100 (acknowledging packet 100)
Now, let’s simulate a packet loss. Client A sends Packet 2.
Packet 2 (Packet Number 101):
- Frame 3: STREAM_DATA, Offset 2000, Length 1000
Packet 3 (Packet Number 102):
- Frame 4: STREAM_DATA, Offset 3000, Length 1000
Suppose Packet 2 (containing data starting at offset 2000) is lost in transit. Server B receives Packet 1 and Packet 3. When Server B sends its next acknowledgement, it will indicate what it has received.
Packet B2 (sent by Server B):
- Frame 2: ACK, Lowest Unacked: 101, Max Unacked: 102, Acknowledge Packet 100, 102
- Range 1: Start 100, End 100
- Range 2: Start 102, End 102
Notice that Packet 101 is missing from the acknowledgement. Client A’s QUIC stack receives Packet B2. It sees that packet 100 and 102 are acknowledged, but 101 is not. This is the key: Client A knows immediately that Packet 101 is likely lost, without waiting for any specific number of duplicate ACKs like TCP’s triple duplicate ACKs. This is the "fast retransmit" aspect.
The retransmission happens almost immediately upon receiving an ACK that shows a gap. Client A then resends Packet 101.
Now, what about "PTO"? PTO stands for Packet Number Delay. It’s a timeout mechanism. Even if Server B is receiving packets perfectly, but it’s slow to send ACKs, or if there’s an issue on the return path preventing ACKs from arriving, Client A will eventually time out.
QUIC uses a sophisticated timer called the PTO timer. This timer is not based on the Round Trip Time (RTT) of a single packet. Instead, it’s based on the RTT of groups of packets. When Client A sends a batch of packets (e.g., packets 100, 101, 102), it starts a PTO timer. This timer is designed to fire if it hasn’t received any acknowledgement for the entire group within a certain time.
The PTO timer’s duration is calculated based on the estimated RTT and the number of packets sent in the current "PTO window." A common PTO period might be around 3 times the RTT, but it’s dynamically adjusted. If the PTO timer fires, Client A assumes that all packets sent since the last successful acknowledgement might be lost and retransmits them. This is a more aggressive approach than TCP’s Retransmission Timeout (RTO), which is typically much longer and less sensitive to individual packet losses.
Here’s how Client A would handle the PTO scenario:
Suppose Server B is overwhelmed and not sending ACKs back.
Client A sends:
Packet 100
Packet 101
Packet 102
Packet 103
Client A starts its PTO timer. If this timer expires before Client A receives an ACK that acknowledges at least Packet 100 (the start of the current PTO window), Client A will retransmit all packets from Packet 100 onwards that haven’t been explicitly acknowledged.
The crucial difference is that QUIC’s PTO is a timer for a group of packets, and it’s often much shorter than TCP’s RTO. It’s a proactive measure to ensure that if any packet in a window is lost and not being acknowledged, the sender doesn’t wait too long.
The real power here is the combination:
- Fine-grained ACKs: QUIC ACKs report on individual packet numbers, allowing for immediate detection of gaps.
- PTO Timer: A group-based timeout that’s more sensitive than TCP’s RTO, triggering retransmissions when acknowledgements for a batch of packets go silent.
Together, these mechanisms allow QUIC to detect and recover from packet loss much faster than traditional TCP, contributing significantly to its performance over lossy networks.
The next hurdle you’ll face after mastering loss recovery is understanding how QUIC handles congestion control.