On Fri, Oct 16, 2026 at 08:13:04PM +0900, Yeonggi Kim wrote:
> Hi Amaury, Frederic,
> While looking at our Retry statistics, I noticed a difference between
> 3.2 and 3.3+ in qc_new_conn(), and I would like to know whether it is
> intended.
> In 3.2, a listener connection created from an Initial packet with an
> already checked token is considered as having a validated peer address,
> whatever the token format. The condition is "token", which is set from
> pkt->token_len. Since 29fb1aee5 ("MINOR: quic-be: QUIC connection
> allocation adaptation (qc_new_conn())", 3.3-dev2), the condition is
> token_odcid->len, which is only set for a Retry token. So a connection
> created with a valid NEW_TOKEN token is now counted in half_open_conn,
> and it is subject to the anti-amplification limit until a Handshake
> packet is received. The commit message only mentions the QUIC backend
> side, so I wonder if this part was intended.
> I checked it with an aioquic client. A first connection gets a
> NEW_TOKEN token, then a second one uses this token while the server
> replies are dropped, so that the handshake does not complete. No Retry
> is emitted, so the token is accepted. While the second connection is
> pending, quic_half_open_conn is 0 on 3.2.23, and 1 on 3.4.7 and on
> current master.This definitely looks like a regression, as the commit you pointed is mostly a reorganization for backend side support. We'll investigate it and provide a fix if needed. Thanks for your observations. -- Amaury Denoyelle
