Summary

HAProxy checks the QUIC handshake and accept caps before evaluating dynamic
Retry. If the handshake cap is no greater than the Retry threshold, tokenless
Initials can fill every slot before Retry is activated. Later Initials are then
dropped by the earlier cap check, so the Retry branch remains unreachable.

Would it make sense to adjust the threshold calculation or check ordering?

Conditions

• A reachable QUIC frontend with forced Retry disabled.
• floor(listener_backlog / 2) <= tune.quic.fe.sec.retry-threshold.
• Valid Initials are sent without completing their handshakes.

For example, maxconn 100 produces 50 handshake slots while the default Retry
threshold remains 100. Filling those 50 slots prevents new handshakes until
their timeout; established connections remain usable.

Relevant code

• quic_rx_pkt_retrieve_conn() checks admission caps before token handling and Retry.
• quic_listener_max_handshake() returns half of the effective backlog.
• listener_backlog() may derive that value from maxconn.

Reviewed on master@e278b8db100fe3a3afe8111af02b7596a86bca0d.

Suggested adjustment

Clamp the effective Retry threshold below the handshake cap, evaluate Retry
before the hard-cap drop, or reject/warn about configurations in which dynamic
Retry cannot activate. Reserving some slots for address-validated peers would
also prevent tokenless Initials from occupying the complete admission budget.