Internet-Draft Structured Connection ID September 2023
Shi Expires 15 March 2024 [Page]
Workgroup:
QUIC
Internet-Draft:
draft-shi-quic-structured-connection-id-01
Published:
Intended Status:
Standards Track
Expires:
Author:
H. Shi
Huawei Technologies

Structured Connection ID Carrying Metadata

Abstract

This document describes a mechanism to carry the metadata in the QUIC connection ID so that the intermediary can perform optimization.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://VMatrix1900.github.io/draft-quic-structured-connection-id/draft-shi-quic-structured-connection-id.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-shi-quic-structured-connection-id/.

Source for this draft and an issue tracker can be found at https://github.com/VMatrix1900/draft-quic-structured-connection-id.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 15 March 2024.

Table of Contents

1. Introduction

Nowadays, media applications are usually able to dynamically adjust the size and quality of the stream to adapt to fluctuating network conditions. However, for the high throughput and low latency media traffic, adaptation only by the endpoint is not good enough, especially when the network condition is challenging, such as the wireless networks discussed in [I-D.kaippallimalil-tsvwg-media-hdr-wireless] and [I-D.defoy-moq-relay-network-handling]. To this end, it is desirable to have the intermediary performing optimization for the endpoint. For example, low-priority packets can be dropped to save the resource when the network is congested.

One example of such an intermediary is the relay in the Media over QUIC working group. To quote the charter from the MoQ working group. "Media over QUIC (moq) will develop a simple low-latency media delivery solution for ingest and distribution of media. This solution addresses use cases including live streaming, gaming, and media conferencing and will scale efficiently." "Even when media content is end-to-end encrypted, the relays can access metadata needed for caching (such as timestamp), making media forwarding decisions (such as drop or delay under congestion), and so on."

Due to the end-to-end encryption of the QUIC, the intermediary does not have the necessary metadata to perform optimization. A similar problem exists when the media is encrypted and transferred using SRTP [RFC3711]. To solve the problem, [I-D.ietf-avtext-framemarking] defines an extension of the RTP header containing the video frame information. This document defines an extension of the QUIC header, using the connection ID to carry the necessary metadata. To mitigate the linkability between the multiple connection IDs of the same connection and protect privacy, the metadata MAY be encrypted and only decrypted by an authenticated intermediary. Similar to [I-D.ietf-quic-load-balancers], a configuration agent is used to distribute the encryption parameters and the template of the metadata.

2. Terminology

This document uses terms in the [I-D.ietf-quic-load-balancers]:

All wire formats will be depicted using the notation defined in Section 1.3 of [RFC9000].

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. Architecture

                             + --------------+
                             | Configuration |
         +-------------------+     agent     +-------------------+
        /                    +------+--------+                    \
       /Config Parameters and template of the Metadata field in CID\
      /                             |                               \
     /          _______             |              _______           \
+---V----+     (       )     +------v-------+     (       )     +-----v----+
| Client +----( Network )----+ Intermediary +----( Network )----+  Server  |
+--------+     (_______)     +--------------+     (_______)     +----------+

Figure 1: Architecture of the intermediary

Figure 1 shows the architecture of the optimization intermediary. The sender endpoint encodes the metadata into the connection ID field (See Section 4). The intermediary performs the related optimization based on the metadata. Since different applications may need to expose different metadata to the intermediary, a template is used to define the content and the format of metadata. The template is determined and distributed by a configuration agent. If the network between the intermediary and endpoints is not trusted by endpoints, the metadata MAY be encrypted. In this case, the parameter for encryption MUST be shared only with the authenticated intermediary through the configuration agent. The means of authentication and the distribution of these parameters and template is not in the scope of this document.

4. Structured Connection ID

Structured Connection ID {
  Config Parameters (8),
  Metadata (40...152),
}
Figure 2: Format of structured CID

The format of the structured connection ID is shown in Figure 2. The content and the format of the metadata field are defined by a template, carrying the information such as media characteristics in Section 3.1 of [I-D.ietf-avtext-framemarking], the service requirement such as delay and importance in Section 5 of [I-D.kaippallimalil-tsvwg-media-hdr-wireless-01].

If an intermediary acts as both the load balancer and the optimization point and they share the same trust relationship, the Metadata and the Server ID defined in [I-D.ietf-quic-load-balancers] can be put together and share the same Config Parameter. Otherwise, if a QUIC connection goes through both the load balancer and optimization point, an additional mechanism is needed for the coexistence of the metadata and the Server ID. The details will be worked out in the later version.

5. Security Considerations

TBD

6. References

6.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3711]
Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, , <https://www.rfc-editor.org/rfc/rfc3711>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9000]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, , <https://www.rfc-editor.org/rfc/rfc9000>.

6.2. Informative References

[I-D.defoy-moq-relay-network-handling]
de Foy, X. and R. Krishna, "MOQ Relays for Support of High-Throughput Low-Latency Traffic", Work in Progress, Internet-Draft, draft-defoy-moq-relay-network-handling-01, , <https://datatracker.ietf.org/doc/html/draft-defoy-moq-relay-network-handling-01>.
[I-D.ietf-avtext-framemarking]
Zanaty, M., Berger, E., and S. Nandakumar, "Video Frame Marking RTP Header Extension", Work in Progress, Internet-Draft, draft-ietf-avtext-framemarking-15, , <https://datatracker.ietf.org/doc/html/draft-ietf-avtext-framemarking-15>.
[I-D.ietf-quic-load-balancers]
Duke, M., Banks, N., and C. Huitema, "QUIC-LB: Generating Routable QUIC Connection IDs", Work in Progress, Internet-Draft, draft-ietf-quic-load-balancers-17, , <https://datatracker.ietf.org/doc/html/draft-ietf-quic-load-balancers-17>.
[I-D.kaippallimalil-tsvwg-media-hdr-wireless]
Kaippallimalil, J., Gundavelli, S., and S. Dawkins, "Media Header Extensions for Wireless Networks", Work in Progress, Internet-Draft, draft-kaippallimalil-tsvwg-media-hdr-wireless-02, , <https://datatracker.ietf.org/doc/html/draft-kaippallimalil-tsvwg-media-hdr-wireless-02>.
[I-D.kaippallimalil-tsvwg-media-hdr-wireless-01]
Kaippallimalil, J. and S. Gundavelli, "Media Header Extensions for Wireless Networks", Work in Progress, Internet-Draft, draft-kaippallimalil-tsvwg-media-hdr-wireless-01, , <https://datatracker.ietf.org/doc/html/draft-kaippallimalil-tsvwg-media-hdr-wireless-01>.

Author's Address

Hang Shi
Huawei Technologies
China