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.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.

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-leave@nginx.org