QUIC-enabled Service Differentiation for Traffic Engineering

Introduction This draft outlines a method that enables a WAN to manage packets from a single QUIC connection with differentiated traffic engineering policies at packet-level granularity. For instance, a WAN can offer two priority routing paths for packets from the same QUIC connection: (1) it directs first-time transmitted packets on a default-priority, low-cost path, and (2) it routes retransmitted packets and handshake packets on a high-priority (low-latency) but more expensive path. Consequently, this approach achieves cost-efficiency and reduces tail latency simultaneously. While there are existing solutions to support Differentiated Service (DiffServ), such as using Differentiated Services Code Point (DSCP) or opening multiple ports to enable QoS control, they have several limitations. For example, DSCP values may be modified by an ISP or a network service provider, and opening multiple ports raises security concerns (more details as discussed in ). The solution proposed in this draft can overcome these limitations, as it is designed with the following properties: (1) The service differentiation encoding is immune to modifications by middleboxes. (2) It provides traffic engineering control at packet-level granularity within a connection. (3) A user-space application can directly control each packet's priority without the kernel's special support. (4) It does not change the deployment method, as current QUIC applications have. In a nutshell, this proposal establishes multiple routing paths at different priority levels inside a single QUIC connection and encodes a packet's routing priority in its CID. Specifically, this proposal reuses mechanisms from Multipath QUIC , but makes two major changes: (1) Multiple QUIC paths are allowed to be created between a single-homed client and server (e.g., the client and server can both have only one (IP, port) address). (2) This proposal leverages different CIDs to describe various priority levels for QUIC packets that belong to the same connection. In this draft, QUIC paths can share the same perceived 4-tuple, but as long as their underlying physical routing paths are not the same, they are treated as different paths. This proposal shares many key similarities to Multipath QUIC: (1) Senders manage per-path congestion status; (2) RTT measurements are per-path. (3) Each path uses a separate packet number space (PNS); (4) A path ID is the sequence number of the CID used to send packets. (5) Once multipath is negotiated, ACK_MP frame is used to acknowledge packets in multiple packet number spaces. The proposed solution is intended to work with edge routers that have segment routing capabilities, such as SRv6 . Note that the QUIC CID is not intended to be directly used for routing in Cloud WAN, but SHOULD be translated to SRv6 SID or an MPLS label by an edge router for traffic engineering purposes.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. This document uses the following terms:

Cloud WAN: The backbone network provided and controlled by a Cloud provider, or the backbone network operated by an application service provider.
Edge router: Edge router of a backbone network.
QUIC path: The path described in Multipath QUIC protocol, which is a logical end-to-end transmission path created by the client.
Routing path: The network path that a packet physically traverses, also specified as the Cloud WAN path in this document.

Alternatives to support service differentiation in traffic engineering This section describes existing solutions that offer service differentiation in traffic engineering and their limitations when applied to the internet. The most commonly used solution is to use the DSCP packet marking for traffic engineering. However, such a solution faces several limitations: (1) A DSCP marker is subject to modifications by an ISP or a network service provider. (2) Marking DSCP on mobile devices may require kernel changes. (3) DSCP is marked at the granularity of connection or session, which means packets with the same 4-tuple are treated with the same priority, and hence, it cannot support packet-level QoS control. The second solution is to use multiple ports, either source or destination ports, to differentiate QoS between two endpoints. When this solution is used, packets with different priorities are sent to sockets bound to different ports. However, such a solution also faces several drawbacks. Source ports may be modified by a NAT in the network, which changes the priority. Using destination ports to support QoS raises security concerns, as opening many ports increases the potential attack surface for cyber threats. Destination ports other than some well-known ports (e.g., 80, 433) may also be subject to blocking by firewalls.

Using Multipath QUIC

New Transport Parameter This draft defines a new transport parameter to claim the adoption of priority paths. It is negotiated during QUIC handshake as described in . The new parameter is defined as PRIORITY_PATHS. This parameter is used to indicate the number of priority levels:

0, 1: Only one path is available, i.e., multiple priority levels are not considered.
n (n > 1): n paths are available, i.e., n priority levels are available for use.

When the client supports PRIORITY_PATHS, it sends a value greater than 1 to the server side. After receiving it, the server returns the configured value of PRIORITY_PATHS to the client. The PRIORITY_PATHS value that a client uses MUST be consistent with the returned value from the server, i.e., the server determines how many priority paths can be used. The server and CID parser share the same PRIORITY_PATHS values, which are configured by the control plane. After negotiation, the client obtains the same value as the server.

QUIC Connection Setup When a QUIC client starts a new connection, it uses a CID generated using the default priority (defined as 0). If PRIORITY_PATHS is supported, a server SHOULD respond with a CID that represents the default priority and indicate to the client that it supports PRIORITY_PATHS.

Paths Setup with More Priorities After QUIC connection negotiation is completed, endpoints need to exchange CIDs with each other. These CIDs are generated using the method described in . illustrates an example of this process. The client sends CIDs with priority 1 and priority 2 (C-CID1 and C-CID2), and the server also sends CIDs representing these two priority levels (S-CID1 and S-CID2).

An example of CID exchange and path setup NEW_CONNECTION_ID[S-CID1] <--- NEW_CONNECTION_ID[S-CID2] (New path init with priority 1) PATH_CHALLENGE[S-CID1] ---> <--- PATH_RESPONSE,PATH_CHALLENGE[C-CID1] PATH_RESPONSE[S_CID1] ---> ]]> After the CID exchange is completed, the client selects S-CID1 to establish a new path of priority 1 via PATH_CHALLENGE frame. Even though the packet that uses S-CID1 comes from the same 4-tuple as the default path (i.e., priority 0), the server SHOULD treat it as a new path establishment request and respond with PATH_RESPONSE and PATH_CHALLENGE frames using a CID of the same path priority, i.e., C-CID1.

Effect of CID rotation When an endpoint rotates to a new CID on an existing path, it will not send PATH_CHALLENGE frame and the new CID does not change the path priority, so the peer will not treat this new CID as an attempt to create a new path.

CID Generation and Parsing

Overview of End-to-end Network

End-to-end network QUIC packets traverse the end-to-end network as described in . This network includes three parts: internet access network, Cloud WAN, and Cloud DCN. The Cloud WAN has various routing paths with different performances, thus priority scheduling is applied. The client and server assign different priorities to the CIDs they generate and send. At the Cloud WAN edge, two CID parsers are responsible for parsing the priority of incoming packets and forwarding them to the appropriate routing path.

CID Generation on the Server Side There are two purposes for encoding the CID: 1. The client and server can understand the priority represented by the CID; 2. There MUST NOT be a correlation between the CID and its priority, which is important to prevent privacy leaks if an attacker observes. Their CIDs are generated on the server side for packets from the client to the server. The format of an encoded CID on the server side is defined below: To prevent the priority value from being observed by an attacker, the server uses encryption (e.g., AES-128-ECS cipher) to obscure the CID, which is similar to . The encryption key and length are pre-configured on the server. Note that when the generated CID is sent to the client through NEW_CONNECTION_ID frame, the Sequence Number in this frame needs to satisfy priority = sequence_number % n (n is described in ). The client will use Sequence Number to calculate priority.

CID Generation on the Client Side Their CIDs are generated on the client side for packets from the server to the client. Its format is the same as the definition in , which is completely random. When the server sends QUIC packets with these CIDs, an additional byte is appended before the first byte of a CID to indicate the priority. The CID parser 2 will remove this byte after receiving these packets from the server. Therefore, CIDs within these packets remain completely random as they were generated on the client side. As they traverse through the Cloud WAN and internet access network, the priority cannot be observed. Moreover, the DCN operates as a private network that attackers typically cannot access.

CID Parsing CID parser 1 parses QUIC packets sent from the client to the server. These packets contain encrypted CIDs. Thus, parser 1 initially decrypts the CIDs (using the same encryption key as the server, which is also pre-configured). For each CID, it only needs to be decrypted once. It then reads the last byte of the CID, which indicates the priority and forwards the packets. CID Parser 2 parses QUIC packets from the server to the client. It extracts the first byte of the CID, which represents the priority, then removes it and forwards the packets. When forwarding a packet, its priority is translated to an SRv6 SID or an MPLS label to map it to the appropriate routing path. Thus, both parsers record the mapping of priority levels to specific traffic engineering policies. The configuration file is issued by the control plane and can be updated during runtime. In the case of SRv6 TE, such a priority level is mapped to SRv6 SIDs as shown below: (SRv6 SID 0) (priority 1） ==> (SRv6 SID 1) (priority 2） ==> (SRv6 SID 2) ]]> Based on the parsed priority, the parser adds the corresponding SRv6 SID to the packet, so that the packet can be routed on the desired priority path. As these operations only include matching, removing bytes, and inserting new headers, they can be efficiently offloaded to hardware.

Examples

Packet Flow from Server to Client shows a typical example that how the packets from a server to a client are routed on different Cloud WAN routing paths according to different CIDs (priorities).

An example of packet flow from server to client CID parser1 <-+ | | +-----+-------+ | | | | +------------------------------------------------------+ | +----v-----+ | ISP edge | +----------+ C+DCID0 || C|DCID1 +-----^--------^------+ | | | +-----------------+ | | | Multipath QUIC | | | +-----------------+ | | | APP client | | | +-----------------+ | | Mobile de^ice | +---------------------+ ]]> The app first describes its priority requirements through the API to the QUIC layer. As shown in this figure, it describes that retransmitted packets should be routed on a high-priority path, while other packets are routed on a default-priority path. When these QUIC packets arrive at the edge of Cloud WAN, the CID parser parses each packet and extracts the priority encoded in the CIDs as described in . Based on the priority, packets are sent on different routing paths via added SRv6 SIDs. For example, low-priority packets will be routed on a default low-cost path, while high-priority packets will routed on a preimum low-latency path. Since packets using different CIDs belong to the same QUIC connection, they will be combined into a complete and ordered stream by QUIC and then submitted to the upper-layer application.

Deployment of CID Parser This section discusses some experiences regarding the deployment of CID parsers in a Cloud WAN. Two issues should be considered in the actual deployment:

Where to deploy?
Translating QUIC CID to SRv6 segment identifiers or MPLS labelling?

For the first one, the parser is usually deployed on the edge of Cloud WAN. For uplink traffic, it is deployed at the intersection of the ISP network; for downlink traffic, it is deployed at the edge routers of a datacenter region. For the second one, this document recommends using SRv6 because it has better scalability and flexibility.

Security Considerations TBD.

IANA Considerations The following entry in Table should be added to the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading: New Transport Parameter

Value	Parameter Name.	Specification
TBD (experiments use 0x5052494f52495459)	PRIORITY_PATHS