Solicit comments and suggestions on Structured Connection ID. FW: New Version Notification for draft-shi-quic-structured-connection-id-02.txt

"Shihang(Vincent)" <shihang9@huawei.com> Sat, 16 March 2024 05:27 UTC

Return-Path: <shihang9@huawei.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6079C14F604 for <quic@ietfa.amsl.com>; Fri, 15 Mar 2024 22:27:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.205
X-Spam-Level:
X-Spam-Status: No, score=-4.205 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8Y4PC5sxtmk for <quic@ietfa.amsl.com>; Fri, 15 Mar 2024 22:27:56 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC4EBC14F61A for <quic@ietf.org>; Fri, 15 Mar 2024 22:27:55 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4TxTzy3fwfz6K8hJ for <quic@ietf.org>; Sat, 16 Mar 2024 13:23:42 +0800 (CST)
Received: from lhrpeml500003.china.huawei.com (unknown [7.191.162.67]) by mail.maildlp.com (Postfix) with ESMTPS id 4E3FC140DE1 for <quic@ietf.org>; Sat, 16 Mar 2024 13:27:53 +0800 (CST)
Received: from kwepemd500009.china.huawei.com (7.221.188.237) by lhrpeml500003.china.huawei.com (7.191.162.67) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Sat, 16 Mar 2024 05:27:52 +0000
Received: from kwepemd100007.china.huawei.com (7.221.188.221) by kwepemd500009.china.huawei.com (7.221.188.237) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Sat, 16 Mar 2024 13:27:50 +0800
Received: from kwepemd100007.china.huawei.com ([7.221.188.221]) by kwepemd100007.china.huawei.com ([7.221.188.221]) with mapi id 15.02.1258.028; Sat, 16 Mar 2024 13:27:47 +0800
From: "Shihang(Vincent)" <shihang9@huawei.com>
To: "quic@ietf.org" <quic@ietf.org>
Subject: Solicit comments and suggestions on Structured Connection ID. FW: New Version Notification for draft-shi-quic-structured-connection-id-02.txt
Thread-Topic: Solicit comments and suggestions on Structured Connection ID. FW: New Version Notification for draft-shi-quic-structured-connection-id-02.txt
Thread-Index: Adp3YqxCD8zANx68QTq3rnF01NVeRQ==
Date: Sat, 16 Mar 2024 05:27:47 +0000
Message-ID: <c3d39f7a83c74db6b64d195727568be4@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.200.88]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ufUQHBepy6erusT72RCiNHDjSxI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2024 05:27:57 -0000

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: internet-drafts@ietf.org <internet-drafts@ietf.org> 
Sent: 2024年3月4日 20:05
To: Shihang(Vincent) <shihang9@huawei.com>
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