Single-packet probes need 6 PTO doublings (~19s) to land one datagram
through the `amplificationlimit` interop scenario's 6-drop window.
quic-go and msquic kill the connection at ~10s of silence regardless
of our handshake-timeout budget, so we never recovered against them
(diagnosed in the parent investigation; the 10s→30s timeout bump in
0a892b0d4b only fixed picoquic).
RFC 9002 §6.2.4 allows up to 2 ack-eliciting packets per PTO. Adding
the second probe halves recovery to ~3 PTO rounds (~5s) and lands
within strict server tolerances.
Wiring:
- New `QuicConnection.pendingProbePackets`, set to 2 by handlePtoFired.
- Extracted `requeueInflightForProbe` from handlePtoFired so the send
loop can re-requeue inflight CRYPTO / STREAM bytes between probes.
- Send loop decrements the budget after each probe-bearing send; if
the budget is still positive, re-requeues AND re-arms `pendingPing`
so the no-data fallback (post-handshake idle) still emits a second
PING. Without the `pendingPing` re-arm, only the first probe fires
when CRYPTO is fully ACK'd — `pendingPing` is one-shot in
collectHandshakeLevelFrames.
Verified end-to-end:
- amplificationlimit: ✕→✓ vs quic-go (35s→7s); ✓ no-regression vs
picoquic (19s→7s) and quinn (15s→7s); msquic now reports server-
side UNSUPPORTED (was failing). Recovery times across the board
drop ~3x because handshake-loss recovery is ~3 PTO rounds instead
of ~6.
- handshake / transfer / multiplexing / handshakeloss all green vs
quic-go, quinn, picoquic, msquic — no regression on the core matrix.
Tests:
- New `ptoEmitsTwoProbePacketsPerRfc9002` in PtoCryptoRetransmitTest
invokes the EXACT helpers the send loop uses (handlePtoFired then
requeueInflightForProbe between drains) and asserts two distinct
Initial datagrams with the same CRYPTO bytes at offset 0 on
distinct PNs. Verified the test fails when budget is reverted to 1.
- Existing PTO + recovery tests stay green.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Vitor Pamplona
0c4bf031f1