On Thu, Oct 30, 2025 at 7:12 AM Mike Bishop <mbishop= [email protected]> wrote:
> To provide some additional context on this, there are two main goals here. > First, sharing the other side's real-time perspective on network state can > be useful in choosing application-level behavior (e.g. ABR). Second, > recalling data from a previous connection can be useful with > transport-level optimizations such as Careful Resume ( > https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-careful-resume-24). > It is already possible for the server to embed this recall data in Address > Validation tokens, but that's opaque to clients and there's overlap with > data that the client might wish to consume. > > This extension enables each side to share network information with the > peer over the course of the connection, optionally having some of the > values passed back to it on a future connection. > Having a standard way to query for debug information for a QUIC or TCP connection that multiple vendors implement does seem very useful. It would help for inter-op and comparing the behavior of implementations. For example QUIC BBR implementations. 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? This debug endpoint could be implemented not just QUIC but also HTTP/1.1 and HTTP/2 endpoints. Not having to change the QUIC framing layer seems simpler and more generally applicable. > Since the peer (generally the client, but that's not a requirement) can > inspect the information, it can make a more informed choice about whether > it wants to echo back the prior state or start fresh for privacy reasons. > 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. Information about the client could be encoded in the *opaque integrity tag*, max congestion window, RTT variance, and other proposed fields. > Chairs, might this have a few minutes in As Time Permits? > > -Mike Bishop (no hat) > ------------------------------ > *From:* 袁靖昊 <[email protected]> > *Sent:* Sunday, October 19, 2025 10:47 AM > *To:* [email protected] <[email protected]> > *Subject:* New ID--Exchanging Congestion Control Data in QUIC > > Hello colleagues at QUIC WG. > > I'm Yuan Jinghao from ByteDance, and I'd like to introduce to you a draft > we recently submitted. > > We have noticed that in various scenarios, there is a demand to represent > and consume congestion control status. Based on this, we have constructed a > custom QUIC frame, which is composed of multiple Network Statistics. Every > "Network Statistics" records network signals such as bandwidth, packet > loss, and RTT, etc. This extension allows peers to exchange their cc status > and enables the original data to be echoed back to the source in a secure > form. > > We have applied the prototype of this draft in live streaming for several > years and achieved actual QoE benefits. > > We hope that this extension can not only be applied in TikTok live but > also receive professional evaluations and guidance from the industry. > > Thanks, > > Jinghao Yuan > > draft-00: > https://datatracker.ietf.org/doc/draft-yuan-quic-congestion-data/ >
