Hello! On Tue, Sep 27, 2022 at 04:05:54PM +0400, Sergey Kandaurov wrote:
> > 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. Shouldn't it be at the "info" level, much like other client-related errors? -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list -- nginx@nginx.org To unsubscribe send an email to nginx-le...@nginx.org