> On 27 Sep 2022, at 14:11, João Sousa Andrade <joao.andr...@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-le...@nginx.org
