On Wed, Nov 5, 2025 at 5:59 AM Salz, Rich <[email protected]> wrote:
> > - I'm just wondering if the stated goal be achieved by exposing a > well-known HTTP path endpoint that clients can use to query congestion > param data for the current connection? > > > Wouldn’t that require a separate endpoint for potential every/many clients? > I was thinking about something similar to the /.well-known/ paths used by the ACME protocol. The answer at these endpoints would depend on properties of the current QUIC (or TCP) connection. We can have the conversation on which approach is simpler and more general. I can see the value of both approaches. Either would be an improvement from the current situation where there is no standard way to query the other end's CC state. > > - The client can inspect the information provided by the server, but > there is no guarantee that the server will provide congestion param cookies > that do not uniquely identify the client. > > > The server can already do that in the address validation token which is > opaque to the client. > Right. There is already a way for servers to associate resumption tokens with client IPs and inject information about CC params in an opaque and authenticated way via the address validation token. Do we need a second mechanism that also needs an opaque authenticator in order to avoid creating a potential abuse vector?
