**Session Date/Time:** 19 Mar 2025 06:00

# quic

## Summary

This QUIC working group meeting covered several important topics, including updates on QLOG, multipath QUIC, address discovery, receive timestamps, extended key updates, source offer management, and a proposal for QUIC multiplexing over other reliable transport protocols (QMUX). The discussions highlighted the need for clear messaging, careful consideration of use cases, and the potential benefits of standardization for future protocol development. Several polls were taken to gauge interest in proposed work items.

## Key Discussion Points

*   **QLOG:** Updates are minimal, mostly related to TLS and editorial issues. QLOG extensions for RTP over QUIC and media over QUIC are in progress in other working groups. Clearer guidance on writing new QLOG entries is needed. The proposal to revamp the quickwg.org website was discussed.
*   **Multipath QUIC:** Updates included CID blocking, handling PTOs, and clarifications on packet content. Hackathon interoperability testing was successful. The utility of the PACEIDs blocked frame was debated, with a decision to keep it for debugging purposes. Martin Duke raised concerns about scheduling and congestion control, suggesting constraining use cases in the document. Mohsen and others raised concerns about limited implementation experience. It was suggested to make the document more clear on this not being a complete solution.
*   **Address Discovery:** The negotiation mechanism using a transport parameter was discussed, with a question of whether it could be simplified. No change to the status quo was decided.
*   **Receive Timestamps:** The extensible act frame approach with multiple optional fields was debated versus other approaches. Questions were raised about handling multi-path, especially ECN. There was discussion about where to place such information and the best framing approach.
*   **Extended Key Update:** The benefits of fresh key exchanges for long-lived sessions were presented, but there were questions regarding TLS context retention and the practicality of long-lived QUIC connections due to NAT issues.
*   **Source Offer Management (Bufferbloat):** Discussed the issue of bufferbloat at the source in QUIC implementations and the need to provide feedback to applications. Implementers were encouraged to review and contribute to the document.
*   **QMUX (QUIC Multiplexing):** Alan presented the proposal for QUIC multiplexing over other reliable bidirectional channels. The discussion focused on messaging, use cases, and whether QUIC is the right venue for standardization. There was support for the general idea, particularly for the standardization of APIs. There were concerns on keeping this effort in alignment with future work. It was recognized that this would likely require a re-charter.

## Decisions and Action Items

*   **QLOG:** Chairs to raise an issue for clarifying QLOG writing new QLOG entries process, maybe talk to AD/RAD.
*   **Multipath QUIC:** Address concerns about scheduling, congestion control, and deployment status by revising the text. Add a text to the introduction maybe mentioning that the failover case is kind of the straightforward one that is a main focus. Chairs will proceed with working group last call for four weeks.
*   **Address Discovery:** Keep the current negotiation mechanism using transport parameters as is.
*   **Receive Timestamps:** The Working group should pursue adding receive timestamps, however, the implementation approach is to be resolved.
*   **Extended Key Update:**  Explore a design that doesn't rely on the TLS crypto stream. Address concerns from participants.
*   **QMUX:** The Working Group should determine a path forward for what is the proper way to define this. Chair will follow up with mail to the list on what the process will look like and how the discussion will evolve. Review the slides that discuss the process for further information.

## Next Steps

*   Authors to update drafts based on feedback received.
*   Chairs to schedule further discussions on the mailing list.
*   QUIC WG to prepare for last call on the Multipath QUIC draft.
*   QUIC WG to determine if QMUX and Abstract API is something the working group should adopt.
*   QUIC WG to examine potential charter adjustments.