Running nginx-quic in a real environment
mdounin at mdounin.ru
Tue Sep 27 21:04:31 UTC 2022
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.andrade at 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
More information about the nginx