On 10/16/26 14:03, Amaury Denoyelle wrote:
> 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.
>
Hi,
Thank you for this report. I will take a look at it asap.
Fred.
