Hi QUIC wg, I would like to share a draft https://datatracker.ietf.org/doc/draft-shi-quic-structured-connection-id/[1] and hear your opinion. Inspired by the use case outlined in https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/[2], my proposal empowers hosts to convey crucial media metadata (such as I frame/P frame/Frame size/Burst/Delay requirements) to the network using QUIC Connection ID. This proactive approach aims to optimize resource management, thereby maximizing network utilization and enhancing application performance.
Building upon the existing architecture of the https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers[3], my proposal expands the server ID to incorporate a metadata field within the connection ID. Since the metadata may vary between different types of applications and networks, the metadata template is introduced. You may find similarities between my proposal and https://datatracker.ietf.org/doc/draft-zmlk-quic-te/[4], which was presented during IETF 117 and faced certain critiques. To address potential concerns, I've engaged in private discussions with several people and iterated on the draft accordingly. Here's how my proposal tackles some key issues: 1. Why not DSCP? Because media metadata will vary packet by packet, there is not enough space in DSCP. 2. What about privacy? Learning from past endeavors, the metadata included in the connection ID strictly pertains to the characteristics and requirements of the application traffic, without divulging a specific user identification. By employing a standardized metadata template, transparency is enhanced, and the risk of fingerprinting can be minimized, especially if templates are governed by an IANA registry(see Option 1 in Section 3). 3. What about trust? Similar to the encryption employed in the QUIC load balancer for server IDs, the metadata within the QUIC connection ID can be encrypted and authenticated. This ensures that untrusted nodes cannot tamper with or monitor the metadata. Moreover, leveraging existing encryption mechanisms or developing stronger ones, such as deriving a separate key for Connection ID protection akin to QUIC header protection, can further improves its security. Despite my effort to mitigate those fundamental concerns, I recognize that additional perspectives and insights are invaluable. Therefore, I eagerly invite your comments and suggestions on this proposal. I am currently in Brisbane this week and would greatly appreciate the opportunity to discuss this further and hear your opinions. Thanks, Hang [1] https://datatracker.ietf.org/doc/draft-shi-quic-structured-connection-id/ [2] https://datatracker.ietf.org/doc/draft-kaippallimalil-tsvwg-media-hdr-wireless/ [3] https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers [4] https://datatracker.ietf.org/doc/draft-zmlk-quic-te/ -----Original Message----- From: [email protected] <[email protected]> Sent: 2024年3月4日 20:05 To: Shihang(Vincent) <[email protected]> Subject: New Version Notification for draft-shi-quic-structured-connection-id-02.txt A new version of Internet-Draft draft-shi-quic-structured-connection-id-02.txt has been successfully submitted by Hang Shi and posted to the IETF repository. Name: draft-shi-quic-structured-connection-id Revision: 02 Title: Structured Connection ID Carrying Metadata Date: 2024-03-04 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/archive/id/draft-shi-quic-structured-connection-id-02.txt Status: https://datatracker.ietf.org/doc/draft-shi-quic-structured-connection-id/ HTML: https://www.ietf.org/archive/id/draft-shi-quic-structured-connection-id-02.html HTMLized: https://datatracker.ietf.org/doc/html/draft-shi-quic-structured-connection-id Diff: https://author-tools.ietf.org/iddiff?url2=draft-shi-quic-structured-connection-id-02 Abstract: This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization. The IETF Secretariat
