Multipath Extension for QUIC

5.1. Multipath QUIC Interaction

Figure 1 illustrates the Multipath QUIC interaction process.¶

Server                     Client                               Server
          Path 2                                Path 1

                              Initial (DCID=A, SCID=B,
                              ClientHello(max_sub_conn_index=4)) ->

                                            Handshake(DCID=B, SCID=C,
                                         <- EE(max_sub_conn_index=4))

                                            Pkt(DCID=B, SCID=C,
                                    <- frames=[New_connection_id(E)])

                              Pkt(DCID=C, SCID=B,
                              frames=[New_connection_id(E)]) ->

                     (Detect new path 2)

                  Pkt(DCID=E,
    frames=[MP_SUB_CONN_NEW(
              <- SCI=2, X)])

Pkt(DCID=F,
frames=[MP_SUB_CONN_ACCEPT(
SCI=2, X)],
PATH_CHALLENGE(Y))  ->

                  Pkt(DCID=E,
<- frames=[PATH_CHALLENGE(Y)])

                    (Data transmission)

        Pkt(DCID=E, pktnum=N1,
<- frames=[STREAM("Request 2")])

Pkt(DCID=F, pktnum=N2,
frames=[MP_ACK(SCI=2, N1),
STREAM("Response 2")]) ->

                              Pkt(DCID=C, pktnum=M1,
                              frames=[STREAM("Request 1")]) ->

        Pkt(DCOD=E, pktnum=N3,
    frames=[MP_ACK(SCI=2, N2),
      <- STREAM("Request 3")])

                                               Pkt(DCID=B, pktnum=M2,
                                           frames=[MP_ACK(SCI=1, M1),
                                            <- STREAM("Response 1")])

Pkt(DCID=F, pktnum=N4,
frames=[MP_ACK(SCI=2, N3),
STREAM("Response 3")]) ->

                              Pkt(DCID=C, pktnum=M3,
                              frames=[MP_ACK(SCI=1, M2),
                              MP_ACK(SCI=2, N4)]) ->

The process is composed of four phases.¶

A. Handshake negotiation¶

During the QUIC-Transport [I-D.ietf-quic-transport] handshake, endpoints negotiate whether multipath feature is supported. The negotiation parameter (see Section 4) is carried within the transport parameters of TLS cryptographic handshake. After the handshake finished, the connection contains the initial sub-connection with SCI equals 1. In Figure 1, the maximum sub-connection index is four.¶

B. Exchange unused Connection ID in advance¶

After the two endpoints complete the connection establishment, they can exchange unused Connection IDs by NEW_CONNECTION_ID frame. Before an endpoint starts to create a new sub-connection, it SHOULD check if there are unused Connection IDs for both endpoints.¶

Note: QUIC-Transport [I-D.ietf-quic-transport] requires Connection ID is uniquely mapped with 2-tuple of IP address and port. If client attempts to use a new 2-tuple as source address to establish a new sub-connection, a new Connection ID is required for client, and also a new Connection ID is required for server.¶

C. New sub-connection establishment¶

During this phase, a new sub-connection is established between client and server, and address validation is needed.¶

When client detects a new network path, it MAY attempts to establish a new sub-connection by sending MP_NEW_SUB_CONN frame which carries a 64-bit random value and claims the new sub-connection's SCI (which is 2 in the example flow in Figure 1). The establishment of sub-connection is always initiated by client.¶

After the server receives the MP_NEW_SUB_CONN frame from the client, it responds with MP_SUB_CONN_ACCEPT frame which carries the identical 64-bit random value from the received MP_NEW_SUB_CONN frame and agrees with the sub-connection's SCI (2 in the example). Server MUST also perform path validation following the procedure specified in QUIC-Transport [I-D.ietf-quic-transport]. Once the server successfully validates its' peers' address, the new sub-connection is established.¶

D. Data transmission on new sub-connection¶

As soon as sub-connections are established, endpoints can communicate with each others over the newly established sub-connections. All valid short header packets defined in QUIC-Transport [I-D.ietf-quic-transport] can be carried on these sub-connections. Every sub-connection has its' independent PNS. Thus, standard QUIC ACK frames defined in QUIC-Transport [I-D.ietf-quic-transport] only acknowledge packets that belong to the same PNS of the sub-connection on which the ACK frames were received.¶

To enable endpoints reply acknowledgements on different sub-connections rather than the sub-connection where the corresponding packets were received, a new type of frame, MP_ACK, is defined. MP_ACK frames can also be replied over the same sub-connection on which data packets were received. In this case, MP_ACK frames serves very similar purposes as QUIC ACK frames do.¶

MP_ACK frame contains the sub-connection index of the packets to be acknowledged. For example, in Figure 1, the packet (packet number is N4) is sent via the second sub-connection (SCI is 2), and its corresponding acknowledgement MP_ACK(Sub-Connection Index=2, N4) is sent via the initial sub-connection.¶

5.2. Path validation and sub-connection ID negotiation

Before clients initiate new sub-connections by sending MP_SUB_CONN_NEW frames to servers through their additional network addresses, they MAY want to validate the reachability between their new network addresses and servers' addresses. In this case, clients can initiate a path validation procedure as specified in QUIC-Transport [I-D.ietf-quic-transport] per address pair.¶

Path validation uses the PATH_CHALLENGE and PATH_RESPONSE frame defined in QUIC-Transport [I-D.ietf-quic-transport].¶

Each sub-connection MUST has a unique pair of SCID and DCID within a multipath QUIC connection. Thus, endpoints MUST NOT initiate or accept new sub-connections if they currently have no free CIDs supplied by their peers. In this case, endpoints SHOULD announce new free CIDs to their peers by exchanging NEW_CONNECTION_ID frames.¶

To ensure that endpoints have free CIDs to create new sub-connections as soon as they get new network addresses, an endpoint SHOULD announce a least one free CID to its peer by sending NEW_CONNECTION_ID frame [I-D.ietf-quic-transport] over its initial sub-connection as soon as the handshake on the initial sub-connection is completed. Endpoints MAY also track the number of free CIDs that their peers can use and announce more free CIDs if needed.¶

Sub-connection ID negotiation follows the Connection ID negotiation method in Connection Migration defined in QUIC-Transport [I-D.ietf-quic-transport], which is to let client and server claim its own unused Connection ID in advance by NEW_CONNECTION_ID frame. If there is no available unused Connection ID, then establishment of new sub-connection is not allowed.¶

5.3. New sub-connection establishment

New sub-connection establishment is always initiated by client, by sending MP_NEW_SUB_CONN frame.¶

Because source address(2-tuple of IP address and port) is usually different in the new network path, client needs to generate and claim new Source Connection IDs prior to the new sub-connection establishment.¶

Client that sends the MP_SUB_CONN_NEW frame in 1-RTT packets with short headers, MUST use the unused Connection ID claimed in advance by server as Destination Connection ID. MP_SUB_CONN_NEW frame carries a 64-bit random value, and a SCI (increased progressively).¶

After receiving the MP_SUB_CONN_NEW frame, server responds with MP_SUB_CONN_ACCEPT frame carrying the identical SCI and identical 64-bit random value from the received MP_NEW_SUB_CONN frame. Then, server sends PATH_CHALLENGE to verify the client address.¶

After client receives the PATH_CHALLENGE frame, it replies with PATH_RESPONSE frame In the following 1-RTT packet (short header) to complete the address validation. After the address validation is completed, client and server can send and receive data unrestrictedly on the established sub-connection.¶

Before the client's address validation is completed, server needs to limit the cumulative size of packets it sends to an unvalidated address to three times the size of packets it receives from that address in the new sub-connection (to prevent amplification attack).¶

5.4. Close sub-connection

Both client and server can terminate a sub-connection, by sending MP_SUB_CONN_CLOSE frame that carries a SCI. In scenarios such as client detects the network environment change (client's 4G/Wi-Fi is turned off, Wi-Fi signal is fading to a threshold), or endpoints detect that the quality of RTT or loss rate is becoming worse, client or server can terminate a sub-connection immediately.¶

MP_SUB_CONN_CLOSE frame can be sent via a different sub-connection instead of the sub-connection to be closed.¶

5.5. Sub-connection Lookup

Endpoints use Connection IDs to find the context of a connection. Figure 2 illustrates the Connection context. Each sub-connection's Connection IDs can be mapped to the connection.¶

                                Connection
    +--------------------------------------------------------------+
    |                                                              |
    |                           Sub-Conn 1                         |
    |                                                              |
+------+   IP 1, Port 1  SCI 1 - SCID A, DCID B  IP 3, Port 3  +------+
|      |<----------------------------------------------------->|      |
|Client|                                                       |Server|
|      |<----------------------------------------------------->|      |
+------+   IP 2, Port 2  SCI 2 - SCID C, DCID D  IP 3, Port 3  +------+
     |                                                              |
     |                           Sub-Conn 2                         |
     |                                                              |
     +--------------------------------------------------------------+

In the connection context, client and server can use SCI or Connection ID to find a sub-connection. Note that if sub-connection migration happens, sub-connection's Connection ID need to be renegotiated (See Section 5.6), while the SCI of sub-connection could remain unchanged.¶

5.6. Sub-connection migration

Sub-connection migration follows the Connection Migration defined in QUIC-Transport [I-D.ietf-quic-transport]. When client experiences NAT rebinding (source address is changed), server needs to revalidate the client address.¶

5.7. Sub-connection state machine management

TODO¶

5.8. Sender and Receiver Connection (Sub-connection) States

For each sender and receiver, the sub-connection states include:¶

5.9. Use load balancer in Multipath QUIC

This specification follows the Connection ID negotiation defined in QUIC-Transport [I-D.ietf-quic-transport]. For stateless or low-state load balancers supporting Multipath QUIC, implementations SHOULD use the specification of Connection ID generation and Load balancer routing defined in QUIC-LB [I-D.ietf-quic-load-balancers], guarantee that packets with Connection IDs belonging to the same connection, can be routed to same server.¶

6.1. Overview

For an outgoing packet, the packet scheduler decides which sub-connection the packet shall be transmitted. The concept of packet scheduler in Multipath QUIC is similar to that in MPTCP. As long as more than one path's congestion controller allows for a new packet transmission, the packet scheduler is enabled. However, the proposed packet scheduler in this draft differs from past MPTCP proposals in the following aspects:¶

• We enable dynamic (feedback-based) scheduling strategy with feedback in this proposal to further enhance quality of user experience(QoE) and to facilitate the expression of the application policy-awareness. Such a capability is made available by adding the QoE control signal length field and QoE control signal field in MP_ACK frame (see Section 8.4). With the help of such extension, a receiver is able to interact with a sender's scheduling strategy in real time.¶
• Unlike MPTCP which send ACK packet over the same path, multipath QUIC allows a packet to be acknowledged over a different path, which allows multipath QUIC to better handle the uplink-downlink heterogeneity in wireless networks.¶
• We support application policy-awareness in multipath QUIC. An application can implement both per-connection policies and per-stream policies. For example, a live streaming application is allowed to choose a different policy from a web application. The per-connection policy includes path mode, path preference, scheduling algorithm and packet redundancy strategy. A per-stream policy is associated with user-defined stream priorities to express the applications's intent.¶

6.2. Basic Static Scheduling Strategy

A basic static scheduling strategy consists of four major components:¶

• Path mode: A scheduler may want to decide which sub-connections shall be activated to transmit data. For instance, a scheduler can choose to use only one of the two sub-connections and completely ignore the other one. A scheduler marks the selected sub-connections to be in the "active" state and the un-selected ones in the "inactive" state.¶
• Path preference: Due to the fact that costs of transmitting data over different sub-connections are not always equal. For example, the energy (battery) cost over a 5G sub-connection and a Wi-Fi sub-connection are very different, so a user may prefer the Wi-Fi sub-connection when his/her cell phone's battery is low. In another example, transmissions over a Wi-Fi sub-connection and a cellular sub-connection may incur different service charges per packet such that a user prefers to use the Wi-Fi sub-connection over the LTE one. Note that a user's preference may change over time. For instance, certain mobile carriers offer unlimited free data for a particular streaming app. Therefore, the sub-connection priority should be made available in the scheduler.¶
• Sub-connection selection algorithm：A selection algorithm splits packets across different sub-connections and determines the order of sub-connections to be selected. The selection algorithm takes congestion controller states as inputs, such as smoothed RTTs (sRTTs), estimated bandwidths (eBWs) and congestion window sizes (CWNDs) as well as application-defined information such as sub-connection priorities and path states. The outputs of the algorithm is an ordered list of sub-connections to put a packet on. To name a few, some of the commonly used algorithms are:¶
• • Round-Robin: There is no priority. it selects sub-connections one by one in order to transmit data.¶
  • Lowest-RTT: It first chooses the sub-connection with the lowest RTT and feeds packets to it until that sub-connection's congestion window is full. Then it chooses the sub-connection with the second lowest RTT.¶
  • Highest-Sending-Rate: It first chooses the sub-connection with the highest bandwidth and feeds packets to it until that sub-connection's congestion window is full. Then it chooses sub-connection with the second largest bandwidth.¶
• Packet redundancy strategy: One major challenge in multi-path transmission is that a packet loss on the slow sub-connection might block the overall transmission when packets are split across fast-changing sub-connections. As the sub-connection selection algorithm takes inputs from congestion controllers which are basically rough predictions of the network and may not be accurate enough for fast-changing wireless channels, such an imprecise estimation could lead to network overuse/underuse. A solution to this problem is to implement packet redundancy strategy. A redundancy strategy can be applied to only ACK packets (partial redundancy) or all data packets (full redundancy). The multipath QUIC in this draft is designed to enable such flexible redundancy strategies. It is up to the application to determine whether, when, and on which packets to activate transmission redundancy.¶

6.3. Dynamic (feedback-based) Scheduling Strategy

An important feature of this proposal is the capability of dynamic (feedback-based) scheduling. In a dynamic scheduling strategy, a receiver notifies its currently preferred scheduling strategy to a sender. Such feedback information is carried by QoE control signal in MP_ACK frames. The frequency of such feedback can be controlled to limit the amount of extra information. To do so, four types of MP_ACK frames are designed (Figure 8):¶

• Type(i) = 0x22 , with no ECN Counts and no QoE Control Signals¶
• Type(i) = 0x23 , with ECN Counts and no QoE Control Signals¶
• Type(i) = 0x24 , with no ECN Counts and QoE Control Signals¶
• Type(i) = 0x25 , with ECN Counts and QoE Control Signals¶

The type 0x24 and 0x25 give the flexibility of carrying QoE control signals. Given that the sender and the receiver may have different views of the wireless environments, especially in high-mobility scenarios, the QoE control signal allows a synchronization between their viewpoints dynamically. It is up to the application to determine the interpretation of QoE control signal and its encoding method.¶

6.4. Application Policy-Awareness

Applications may have completely different QoE requirements---the interactive applications are delay sensitive, while the video streaming applications are more throughput sensitive. There is thus a trend of cross-layer design that tries to take applications' demands into account when managing paths or scheduling packets. The static scheduling strategy and the dynamic scheduling strategy are used together to fully support application policy-awareness in multipath scheduling. To be more specifically, a 'control plane' is separated from a `data plane' as in software-defined networking. The 'control plane' takes applications' high-level demands (a.k.a intent) as input to generate the corresponding policies, which later are deployed on the 'data plane'. The 'data plane' maps users policies to the 'actions', which control the packet scheduler and other functionalities that the transport implements. To allow maximum design flexibility, the proposed multipath QUIC let applications to access/change every single logic of the packet scheduling and path management. The application policy consists of two layers: per-connection policy and per-stream policy.¶

            per-stream intent                   per-conn policy
 Control e.g. stream prioirity      e.g. path preference, path mode,
 Plane                                        deadline-aware etc
            |                                        |
 -----------|----------------------------------------|-------------
            V                                        V
 Data  +--------+ -                      +------------------------+
 Plane |        |  |                     |                        |
       +--------+  |                     |                +-----+ |
                   |                     |             +->| ... | |
       +--------+  |                     |             |  +-----+ |
       |        |  |                     |             |  +-----+ |
       +--------+  |                     |             +->| ... | |
                   |                     |             |  +-----+ |
       +--------+  | +----------+ chunks |+----------+ |          |
       |        |  ->|  stream  |------->||  packet  |-+    ...   |
       +--------+  | |scheduling|        ||scheduling| |          |
          ...      | +----------+        |+----------+ |  +-----+ |
       +--------+  |                     |             +->| ... | |
       |        |  |                     |             |  +-----+ |
       +--------+  |                     |             |  +-----+ |
                   |                     |             +->| ... | |
       +--------+  |                     |                +-----+ |
       |        |  |                     |           path manager |
       +--------+ -                      +------------------------+
         streams

 High priority  /\  +---------+
                ||  |         |
                ||  +---------+
                ||  +---------+
                ||  |         |
                ||  +---------+
                ||     ...          User-defined priority
                ||  +---------+
 Low priority   ||  |         |
                ||  +---------+
 -----------------------------------------------------------
 High priority  /\  +---------+
                ||  |         |
                ||  +---------+
                ||  +---------+
                ||  |         |
                ||  +---------+
                ||     ...          Default priority
                ||  +---------+
 Low priority   ||  |         |
                ||  +---------+

7.1. Congestion control

Implementations MAY support coupled congestion controllers such as LIA [MPTCP-LIA], OLIA [MPTCP-OLIA]s, and etc., or support decoupled congestion controllers in environments using disjoint network paths.¶

In decoupled congestion control, every sub-connection runs its own congestion controller without interacting with the congestion controllers of other sub-connections. That is to say, in the aspect of congestion control, a sub-connection behaves exactly the same as a normal QUIC connection over the same network path.¶

Each sub-connection MAY choose congestion control algorithm independently.¶

7.2. Packet number space and acknowledgements

Every sub-connection has its' own packet number space for transmitting 1-RTT packets.¶

ACK frame [I-D.ietf-quic-transport] MUST be returned via the same sub-connection on which the corresponding packets were sent.¶

MP_ACK frame can be returned via either a different sub-connection, or the same sub-connection, based on different strategies of sending MP_ACK frames.¶

Note: Only MP_ACK frame returned via the same sub-connection can be used to calculate RTT(round trip time).¶

7.3. Flow control

TODO¶

8.1. MP_SUB_CONN_NEW frame

MP_SUB_CONN_NEW frame(type=0x2a) is used to establish a new sub-connection. The MP_SUB_CONN_NEW frame will specify a SCI and include a 64-bit random value.¶

MP_SUB_CONN_NEW frames are formatted as shown in Figure 5.¶

  MP_SUB_CONN_NEW Frame {
    Type (i) = 0x2a,
    Sub_Connection_Index (i),
    Data (64),
  }

8.2. MP_SUB_CONN_ACCEPT frame

MP_SUB_CONN_ACCEPT frame (type=0x2b) is used by endto accept a new sub-connection, as a response to MP_NEW_SUB_CONN frame.¶

MP_SUB_CONN_ACCEPT frames are formatted as shown in Figure 6, which is identical to the MP_NEW_SUB_CONN frame (Section 8.1).¶

  MP_SUB_CONN_ACCEPT Frame {
    Type (i) = 0x2b,
    Sub_Connection_Index (i),
    Data (64),
  }

8.3. MP_SUB_CONN_CLOSE frame

MP_SUB_CONN_CLOSE frame(type=0x2c..0x2d) is used to close a sub-connection, which is formatted by adding a SCI field to QUIC-Transport [I-D.ietf-quic-transport] CONNECTION_CLOSE frame. The SCI is used to distinguish sub-connections, so each sub-connection can be closed independently.¶

MP_SUB_CONN_CLOSE frames are formatted as shown in Figure 7.¶

  MP_SUB_CONN_CLOSE Frame {
    Type (i) = 0x2c..0x2d,
    Sub_Connection_Index (i),
    Error Code (i),
    [Frame Type (i)],
    Reason Phrase Length (i),
    Reason Phrase (..),
  }

8.4. MP_ACK frame

MP_ACK frame allows for acknowledgements on different sub-connections.¶

MP_ACK frame is formatted by adding a SCI field and QoE signal fields to QUIC-Transport [I-D.ietf-quic-transport] ACK frame.¶

MP_ACK frames are formatted as shown in Figure 8.¶

  MP_ACK Frame {
    Type (i) = 0x22..0x23..0x24..0x25,
    Sub_Connection_Index(i),
    Largest Acknowledged (i),
    ACK Delay (i),
    ACK Range Count (i),
    First ACK Range (i),
    ACK Range (..) ...,
    [ECN Counts (..)],
    [QoE Control Signals Length(8)],
    [QoE Control Signals (..)],
  }

Type(i) = 0x22 , with no ECN Counts and no QoE Control Signals¶

Type(i) = 0x23 , with ECN Counts and no QoE Control Signals¶

Type(i) = 0x24 , with no ECN Counts and QoE Control Signals¶

Type(i) = 0x25 , with ECN Counts and QoE Control Signals¶

8.5. MP_ADD_ADDRESS frame

TODO¶

8.6. MP_REMOVE_ADDRESS frame

TODO¶