QUIC-enabled Service Differentiation for Traffic Engineering

1.1. 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 [RFC2119] [RFC8174] 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.¶

3.1. 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 [RFC9000]. 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.¶

3.2. 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.¶

3.3. 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 Section 4. Figure 1 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).¶

Client                                                  Server

  (CID exchange)
  NEW_CONNECTION_ID[C-CID1]
  NEW_CONNECTION_ID[C-CID2]        --->
                                     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.¶

3.4. 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.¶

4.1. Overview of End-to-end Network

  +--------+
  | Server |
  +--------+
       |
       | Cloud DCN
       |
+------+------+
| CID parser2 |
+------+------+
       |
       | Cloud WAN
       |
+------+------+
| CID parser2 |
+------+------+
       |
       | Internet access
       | network
       |
  +----+---+
  | Client |
  +--------+

QUIC packets traverse the end-to-end network as described in Figure 2. 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.¶

4.2. 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:¶

CID {
  Random Bits (32 .. 152),
  Priority Bits (8),
}

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 [QUIC-LB]. 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 Section 3.1). The client will use Sequence Number to calculate priority.¶

4.3. 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 [RFC9000], 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.¶

4.4. 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:¶

(priority 0） ==> (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.¶

5.1. Packet Flow from Server to Client

Figure 3 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).¶

                                +--------------------+
                | Cloud VM           |
                | +----------------+ |API: priority description
                | |   APP ser^er   | |(retrans_pkts: high_priority)
                | +----------------+ |(other_pkts: default_priority)
                | | Multipath QUIC | |
                | +----------------+ |
                |                    |
                +-------+----+-------+
                        |    |
         Path1[C+DCID0] |    | Path2[C+DCID1]
         (other_pkts)   |    | (retrans_pkts)
+------------------------------------------------------+
|                       |    |              Cloud WAN  |
|                   +---v----v----+                    |
|                 +-+ CID parser2 +-+                  |
|                 | +-------------+ |                  |
|         C+DCID0 |                 |C+DCID1           |
|                 |                 |                  |
|              +--v-+            +--v-+                |
|              | R1 |            | R2 |                |
|              +--+-+            +--+-+                |
|    Regular link |                 | Premium link     |
|                 |                 |                  |
|                 | +-------------+ |                  |
|                 +-> 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 Section 4.4. 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.¶

5.2. 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.¶