> On 27 Sep 2022, at 14:11, João Sousa Andrade <joao.andrade@protocol.ai> wrote:
>
> Thank you for the clarification Sergey.
>
> We have been running http3 in production for the past couple of weeks. There's something we have noticed which I'm not entirely sure as to what is causing it.
>
> We have been getting lots of errors of the form: "[error] 34#34: *338736 quic no available client ids for new path while handling decrypted packet, client: $IP, server: 0.0.0.0:443". I tried looking through the code to little avail. I'm wondering what's causing these errors. Is it something which could be tweaked through configuration?

This happens when QUIC connection continues over a new network path,
known as QUIC connection migration, which should by done by switching
to a new connection ID, but the client didn't previously supply enough
Connection ID to chose from. Normally both peers maintain a set of
unused Connection IDs, which may be needed not only for migration,
but also due to NAT rebinding. Assuming that peers that initiate
connection migration maintain enough connection IDs, a likely reason
of the network path change failure as seen in the above error can be
due to NAT rebinding with the client implementation that doesn't a notion
of connection migration so it didn't sent NEW_CONNECTION_ID frames.
In the case of NAT rebinding the server should send probing frames
over a new network path using next available client Connection ID,
but there were no any, as seen in the above error.
Hope that helps.

--
Sergey Kandaurov

_______________________________________________
nginx mailing list -- nginx@nginx.org
To unsubscribe send an email to nginx-leave@nginx.org