Draft: draft-lmbdhk-quic-multipath

Commentary: I 'm still working on this but need to take a little break now . 
 Thanks ,  . Look good to me . I think these are good editorial fixes . When reviewing , I fixed half a dozen typos , committing the edits directly . I also opened two issues : the text on allocating CID before opening paths should be moved from the introduction of " multiple number spaces " to a common section , maybe the introduction of both spaces ; and , the option 2 of the syntax of the path identifier could be simplified . I had previously opened another issue about moving the text on RTT estimates from " single space " to a common section .
This document specifies multipath extension for the QUIC protocol to
enable the simultaneous usage of multiple paths for a single
connection.
This document specifies an extension to the QUIC v1 QUIC-TRANSPORT to
enable the simultaneous usage of multiple paths for a single
connection.
This document specifies a multipath extension for the QUIC protocol
to enable the simultaneous usage of multiple paths for a single
connection.
This document specifies an extension to QUIC v1 QUIC-TRANSPORT to
enable the simultaneous usage of multiple paths for a single
connection.
This proposal supports the negotiation of either the use of one
packet number space for all paths or the use of separate packet
number spaces per path.  While separate packet number spaces allow
for more efficient ACK encoding especially when different paths have
highly difference latencies, it requires the use of a connection ID.
Therefore both approaches support different use cases as a single
number space can be beneficial in highly constrained networks that do
not benefit from exposing the connection ID in the header.  More
evaluation and implementation experience is needed to either only
select one of the approaches or decide for one mandatory to implement
approach to ensure interoperability.
This proposal supports the negotiation of either the use of one
packet number space for all paths or the use of separate packet
number spaces per path.  While separate packet number spaces allow
for more efficient ACK encoding, especially when paths have highly
difference latencies, this approach requires the use of a connection
ID.  Therefore use of a single number space can be beneficial in
highly constrained networks that do not benefit from exposing the
connection ID in the header.  More evaluation and implementation
experience is needed to select one approach before final
publlication.
This proposal does not cover address discovery and management.
Addresses and the actual decision process to setup or tear down paths
are assumed to be handled by the application that is using the QUIC
multipath extension.  Further, this proposal only specifies a simple
basic packet scheduling algorithm in order to provide some basic
implementation guidance.  However, more advanced algorithms as well
as potential extensions to enhance signaling of the current paths are
expected as future work.
This proposal does not cover address discovery and management.
Addresses and the actual decision process to setup or tear down paths
are assumed to be handled by the application that is using the QUIC
multipath extension.  Further, this proposal only specifies a simple
basic packet scheduling algorithm in order to provide some basic
implementation guidance.  However, more advanced algorithms as well
as potential extensions to enhance signaling of the current path
state are expected as future work.
The difference between Path Identifier and Packet Number Space
Identifier, is that Path Identifier is used in multi-path control
frames to identify a path, and Packet Number Space Identifier is used
in 1-RTT packets and ACK_MP frames to distinguish packet number
spaces for different paths.  Both identifiers have the sam value,
which is the sequence number of the connection ID, if a non-zero
connection ID is used.  If the connection ID is zero length, the
Packet Number Space Identifier is 0, while the Path Identifier is
selected on path establishment.
After completing the handshake and endpoints have agreed to enable
multipath feature, endpoints can start using multiple paths.
After completing the handshake, endpoints have agreed to enable
multipath feature and can start using multiple paths.
If validation succeed, the client can send non-probing, 1-RTT packets
on the new paths.  In contrast with the specification in section 9 of
QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing
packets on a new path indicates an attempt to migrate to that path.
Instead, servers SHOULD consider paths over which non-probing packets
have been received as available for transmission.
The current draft defines PATH_ABANDON frame to inform the peer to
abandon a path, and release the corresponding resources.  More
complex path management can be made possible with additional
extensions (e.g., PATH_STATUS frame in I-D.liu-multipath-quic ).  An
endpoint uses the sequence number of the CID used by the peer for
PATH_ABANDON frames (describing the sender's path identifier).
PATH_ABANDON frame can be sent on any path, not only the path
identified by the Path Identifier field.
At any time in the connection, each endpoint manages a set of paths
that are available for transmission.  At any time, the client can
decide to abandon one of these paths, following for example changes
in local connectivity or changes in local preferences.  After a
client abandons a path, the server will not receive any more non-
probing packets on that path.
If validation succeed, the client can send non-probing, 1-RTT packets
on the new paths.  In contrast with the specification in section 9 of
QUIC-TRANSPORT, the server MUST NOT assume that receiving non-probing
packets on a new path indicates an attempt to migrate to that path.
Instead, servers SHOULD consider new paths over which non-probing
packets have been received as available for transmission.
Each endpoint manages the set of paths that are available for
transmission.  At any time in the connection, each endpoint can
decide to abandon one of these paths, following for example changes
in local connectivity or changes in local preferences.  After a
client abandons a path, the server will not receive any more non-
probing packets on that path.
An endpoint that wants to close a path SHOULD NOT rely on implicit
signals like idle time or packet losses, but instead SHOULD use
explicit request to terminate path by sending the PATH_ABANDON frame.
Both client and server can close a path, by sending PATH_ABANDON
frame which abandons the path with a corresponding Path Identifier.
Once a path is marked as "abandoned", it means that the resources
related to the path can be released.
An endpoint that wants to close a path SHOULD NOT rely on implicit
signals like idle time or packet losses, but instead SHOULD use
explicit request to terminate path by sending the PATH_ABANDON frame
(see path-abandon-frame).
Both endpoints, namely the client and the server, can close a path,
by sending PATH_ABANDON frame (see path-abandon-frame) which abandons
the path with a corresponding Path Identifier.  Once a path is marked
as "abandoned", it means that the resources related to the path can
be released.
QUIC-TRANSPORT allows for closing of connections if they stay idle
for too long.  The connection idle timeout in multipath QUIC is
defined as "no packet received on any path for the duration of the
idle timeout".  It means that if all paths remain idle for the idle
timeout, the connection is implicitly closed.
When only one path is available, servers MUST follow the
specifications in QUIC-TRANSPORT.  When more than one path is
available, servers shall monitor the arrival of non-probing packets
on the available paths.  Servers SHOULD stop sending traffic on paths
through where no non-probing packet was received in the last 3 path
RTTs, but MAY ignore that rule if it would disqualify all available
paths.  Server MAY release the resource associated with paths for
which no non-probing packet was received for a sufficiently long
path-idle delay, but SHOULD only release resource for the last
available path if no traffic is received for the duration of the idle
timeout, as specified in section 10.1 of QUIC-TRANSPORT.  Server
implementations manage the value of the path-idle delay as a trade-
off between keeping resource such as Connection Identifiers in use
for an excessive time, and having to promptly reestablish a path
after a spurious estimate of path abandonment by the client.
QUIC-TRANSPORT allows for closing of connections if they stay idle
for too long.  The connection idle timeout in multipath QUIC is
defined as "no packet received on any path for the duration of the
idle timeout".  When only one path is available, servers MUST follow
the specifications in QUIC-TRANSPORT.
When more than one path is available, servers shall monitor the
arrival of non-probing packets on the available paths.  Servers
SHOULD stop sending traffic on paths through where no non-probing
packet was received in the last 3 path RTTs, but MAY ignore that rule
if it would disqualify all available paths.  Server MAY release the
resource associated with paths for which no non-probing packet was
received for a sufficiently long path-idle delay, but SHOULD only
release resource for the last available path if no traffic is
received for the duration of the idle timeout, as specified in
section 10.1 of QUIC-TRANSPORT.  This means if all paths remain idle
for the idle timeout, the connection is implicitly closed.
Server implementations need to select the sub-path idle timeout as a
trade- off between keeping resources, such as connection IDs, in use
for an excessive time or having to promptly reestablish a path after
a spurious estimate of path abandonment by the client.
Acknowledgements of Initial and Handshake packets MUST be carried
using ACK frames, as specified in QUIC-TRANSPORT.  The ACK frames, as
defined in QUIC-TRANSPORT, do not carry path identifiers.  If for
some reason ACK frames are received in 1-RTT packets while the state
of multipath negotiation is ambiguous, they MUST be interpreted as
acknowledging packets sent on path ID 0.
If endpoints negotiate multipath support with value 1 to use multiple
packet number spaces, they SHOULD use ACK_MP frames instead of ACK
frames to signal acknowledgement of 1-RTT packets on path number 0,
and also 0-RTT packets as specified in handling-of-0-rtt-packets.
An endpoint sending 1-RTT packets MUST use different Connection IDs
on different paths, if non-zero-length Connection IDs are used.
Still, the receiver may observe the same Connection ID used on
different 4-tuples due to, e.g., NAT rebinding.  In such case, the
receiver reacts as specified in Section 9.3 of QUIC-TRANSPORT.
All 0-RTT packets are initially tracked in the "global"
application context.
On the client side, 0-RTT packets are initially sent in the
"global" application context.  The handshake concludes before any
1-RTT packet can be sent or received.  When the handshake
completes, if multipath is negotiated, the tracking of 0-RTT
packets moves from the "global" application context to the "path
ID 0" application context.  That means the sequence number of the
first 1-RTT packets sent by the client will follow the sequence
number of the last 0-RTT packet.
On the server side, the negotiation completes after the client
first flight is received and the the server first flight is sent.
0-RTT packets are received after that.  If multipath is
negotiated, they are considered received on "path ID 0".
In conclusion, 0-RTT packets are tracked and processed with path
identifier 0.
If the multipath option is negotiated to use one packet number space
of all path, the packet sequence numbers are allocated from the
common number space, so that for example path number number N could
be sent on one path and packet number N+1 on another.
ACK frames report the numbers of packets that have been received so
far, regardless of the path on which they have been received.
If one common packet number space is used for all paths, the senders
maintain an association between previously sent packet numbers and
the path over which these packets were sent.  This is necessary to
implement per path congestion control.
When a packet is newly acknowledged, the delay between the
transmission of that packet and its first acknowledgement is used to
update the RTT statistics for the sending path, and to update the
state of the congestion control for that path.
Packet loss detection MUST be adapted to allow for different RTTs on
different paths.  For example, timer computations should take into
account the RTT of the path on which a packet was sent.  Detections
based on packet numbers shall compare a given packet number to the
highest packet number received for that path.
If senders decide to send packets on paths with different
transmission delays, some packets will very probably be received out
of order.  This will cause the ACK frames to carry multiple ranges of
received packets.  The large number of range increases the size of
ACK frames, causing transmission and processing overhead.
Delay acknowledgement to allow for arrival of "hole filling"
packets.
If the connection ID is present (non-zero length) in the packet
header, the connection ID is used to identify the path.  If no
connection ID is present, the 4 tuple identies the path.  The initial
path that is used during the handshake (and multipath negotiation)
has the path ID 0 and therefore all 0-RTT packets are also tracked
and processed with the path ID 0.  For 1-RTT packets the path ID is
the sequence number of the Destination Connection ID present in the
packet header, as defined in Section 5.1.1 of QUIC-TRANSPORT, or also
0 if the Connection ID is zero-length.
If the multipath option is negotiated to use one packet number space
for all paths, the packet sequence numbers are allocated from the
common number space, so that, for example, packet number N could be
sent on one path and packet number N+1 on another.
ACK frames report the numbers of packets that have been received so
far, regardless of the path on which they have been received.  That
means the senders needs to maintain an association between sent
packet numbers and the path over which these packets were sent.  This
is necessary to implement per path congestion control.
When a packet is acknowledged, the state of the congestion control
MUST be updated for the path where the acknowledged packet was
originally sent.  The RTT is calculated based on the delay between
the transmission of that packet and its first acknowledgement (see
Section compute-rtt) and is used to update the RTT statistics for the
sending path.
Also loss detection MUST be adapted to allow for different RTTs on
different paths.  For example, timer computations should take into
account the RTT of the path on which a packet was sent.  Detections
based on packet numbers shall compare a given packet number to the
highest packet number received for that path.
Using the default algorithm specified in QUIC-RECOVERY. would result
in suboptimal performance, computing average RTT and standard
deviation from a series of different delay measurements of different
combined paths.  At the same time, early tests show that it is
desirable to send ACKs through the shortest path, because a shorter
ACK delay results in a tighter control loop and better performances.
The tests also showed that it is desirable to send copies of the ACKs
on multiple paths, for robustness if a path experiences sudden
losses.
Using the default algorithm specified in QUIC-RECOVERY would result
in suboptimal performance, computing average RTT and standard
deviation from a series of different delay measurements of different
combined paths.  At the same time, early tests show that it is
desirable to send ACKs through the shortest path, because a shorter
ACK delay results in a tighter control loop and better performances.
The tests also showed that it is desirable to send copies of the ACKs
on multiple paths, for robustness if a path experiences sudden
losses.
An early implementation mitigated the delay variation issue by using
time stamps, as specified in [QUIC-Timestamp].  When the timestamps
are present, the implementation can estimate the transmission delay
on each one-way path, and can then use these one way delays for more
efficient implementations of recovery and congestion control
algorithms.
An early implementation mitigated the delay variation issue by using
time stamps, as specified in QUIC-Timestamp.  When the timestamps are
present, the implementation can estimate the transmission delay on
each one-way path, and can then use these one way delays for more
efficient implementations of recovery and congestion control
algorithms.
If the multipath option is enabled with a value of 1, each path has
its own packet number space for transmitting 1-RTT packets and a new
ACK frame format is used as specified in mp-ack-frame which
additionally contains a Packet Number Space Identifier (PN Space ID).
The PN Space ID used to distinguish packet number spaces for
different paths and is simply derived from the sequence number of
Destination Connection ID.  Therefore, the packet number space for
1-RTT packets is specific to the Destination Connection ID in these
packets.
Note: Even if the use of multiple packet number spaces is negotiated
but a peer uses an zero length connection ID, then all packets sent
to that peer MUST be numbered in a single number space (as specified
in the previous section), because the packet level decryption
implementation will only see one Connection ID sequence number (the
default number 0).
Endpoints can find which path a received packet belongs to according
to the Destination Connection ID of the 1-RTT packet.  Endpoints
identify the context of a path by its Connection ID or the Sequence
number of Connection ID.
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames
to issue usable connections IDs to reach it.  Before an endpoint adds
a new path, it MUST check whether there is at least one unused
available Connection ID for each side.
If the multipath option is enabled with a value of 2, each path has
its own packet number space for transmitting 1-RTT packets and a new
ACK frame format is used as specified in mp-ack-frame.  Compared to
the QUIC v1 ACK frame, the MP_ACK frames additionally contains a
Packet Number Space Identifier (PN Space ID).  The PN Space ID used
to distinguish packet number spaces for different paths and is simply
derived from the sequence number of Destination Connection ID.
Therefore, the packet number space for 1-RTT packets can be
identified based on the Destination Connection ID in each packets.
Following QUIC-TRANSPORT, each endpoint uses NEW_CONNECTION_ID frames
to issue usable connections IDs to reach it.  Before an endpoint adds
a new path by initiating path validation, it MUST check whether at
least one unused Connection ID is available for each side.
Section 5.3 of QUIC-TLS specifies AEAD usage, and in particular the
use of a nonce, N, formed by combining the packet protection IV with
the packet number.  QUIC multipath uses multiple packet number
spaces, and thus the packet number alone would not guarantee the
uniqueness of the nonce.  In order to guarantee this uniqueness, we
construct the nonce N by combining the packet protection IV with the
packet number and with the identifier of the path, which for 1-RTT
packets is the Sequence Number of the Destination Connection ID
present in the packet header, as defined in Section 5.1.1 of QUIC-
TRANSPORT, or zero if the Connection ID is zero-length.  Section 19
of QUIC-TRANSPORT encodes this Connection ID Sequence Number as a
variable-length integer, allowing values up to 2^62-1; for QUIC
multipath, we require that a range of no more than 2^32-1 values be
used without updating the packet protection key.
For QUIC multipath, the construction of the nonce starts with the
construction of a 96 bit path-and-packet-number, composed of the 32
bit Connection ID Sequence Number in byte order, two zero bits, and
the 62 bits of the reconstructed QUIC packet number in network byte
order.  If the IV is larger than 96 bits, path-and-packet-number is
left-padded with zeros to the size of the IV.  The exclusive OR of
the padded packet number and the IV forms the AEAD nonce.
The Key Phase bit update process for QUIC v1 is specified in
Section 6 of QUIC-TLS.  The general principles of key update are not
changed for Multipath QUIC.  Following QUIC V1, the Key Phase bit is
used to indicate which packet protection keys are used to protect the
packet.  The Key Phase bit is toggled to signal each subsequent key
update.  Because of network delays, packets protected with the older
key might arrive later than the packets protected with the new key.
Therefore, the endpoint needs to retain old packet keys to allow
these delayed packets to be processed and it must distinguish between
the new key and the old key.  In QUIC V1, this is done using packet
numbers so that the rule is made simple: Use the older key if packet
number is lower than any packet number frame the current key phase.
When using multiple packet number space on different paths, some care
is needed in the initiating Key Update process.  Because different
paths use different packet number spaces but share a single key.
When a key update is initiated on one path, packets sent to the other
path needs to know when transition is complete.  Otherwise, it is
possible that the other paths send packets with the old keys, but
skip sending any packets in the current key phase and directly jump
to sending packet in the next key phase.  When that happens, as the
endpoint can only retain two sets of packet protection keys with the
1-bit Key Phase bit, the other paths cannot distinguish which key
should be used to decode received packets, which results in a key
rotation synchronization problem.
In order to guarantee the uniqueness of the None, the nonce N is
calculated by combining the packet protection IV with the packet
number and with the path identifier.
The path ID for 1-RTT packets is the sequence number of of QUIC-
TRANSPORT, or zero if the Connection ID is zero-length.  Section 19
of QUIC-TRANSPORT encodes the Connection ID Sequence Number as a
variable-length integer, allowing values up to 2^62-1; in this
specification a range of less than 2^32-1 values MUST be used before
updating the packet protection key.
To calculate the nonce, a 96 bit path-and-packet-number is composed
of the 32 bit Connection ID Sequence Number in byte order, two zero
bits, and the 62 bits of the reconstructed QUIC packet number in
network byte order.  If the IV is larger than 96 bits, the path-and-
packet-number is left-padded with zeros to the size of the IV.  The
exclusive OR of the padded packet number and the IV forms the AEAD
nonce.
The Key Phase bit update process for QUIC v1 is specified in
Section 6 of QUIC-TLS.  The general principles of key update are not
changed in this specification.  Following QUIC v1, the Key Phase bit
is used to indicate which packet protection keys are used to protect
the packet.  The Key Phase bit is toggled to signal each subsequent
key update.  Because of network delays, packets protected with the
older key might arrive later than the packets protected with the new
key.  Therefore, the endpoint needs to retain old packet keys to
allow these delayed packets to be processed and it must distinguish
between the new key and the old key.  In QUIC V1, this is done using
packet numbers so that the rule is made simple: Use the older key if
packet number is lower than any packet number frame the current key
phase.
When using multiple packet number spaces on different paths, some
care is needed when initiating the Key Update process, as different
paths use different packet number spaces but share a single key.
When a key update is initiated on one path, packets sent to another
path needs to know when the transition is complete.  Otherwise, it is
possible that the other paths send packets with the old keys, but
skip sending any packets in the current key phase and directly jump
to sending packet in the next key phase.  When that happens, as the
endpoint can only retain two sets of packet protection keys with the
1-bit Key Phase bit, the other paths cannot distinguish which key
should be used to decode received packets, which results in a key
rotation synchronization problem.
To address such a synchronization issue, if key update is initilized
on one path, the sender SHOULD send at least one packet with the new
key on all active paths.  Regarding the responding to Key Update
process, the endpoint MUST NOT initiate a subsequent key update until
a packet with the current key has been acknowledged on each path.
Following the Section 5.4. of QUIC-TLS, the Key Phase bit is
protected, so sending multiple packets with Key Phase bit flipping at
the same time should not cause linkability issue.
To address such a synchronization issue, if key update is initilized
on one path, the sender SHOULD send at least one packet with the new
key on all active paths.  Further, an endpoint MUST NOT initiate a
subsequent key update until a packet with the current key has been
acknowledged on each path.
Following Section 5.4 of QUIC-TLS, the Key Phase bit is protected, so
sending multiple packets with Key Phase bit flipping at the same time
should not cause linkability issue.
As shown in fig-example-new-path, client provides one unused
available Connection ID (C1 with sequence number 1), and server
provides two available Connection IDs (S1 with sequence number 1, and
S2 with sequence number 2).  When client wants to start a new path,
it checks whether there is unused available Connection IDs for each
side, and choose an available Connection ID S2 as the Destination
Connection ID in the new path.
Endpoints need to exchange unused available Connection IDs with the
NEW_CONNECTION_ID frame before an endpoint starts a new path.  For
example, if the goal is to maintain 2 paths, each endpoint should
provide at least 3 CID to its peer: 2 in use, and one spare.  If the
client has used all the allocated CID, it is supposed to retire those
that are not used anymore, and the server is supposed to provide
replacements, as specified in QUIC-TRANSPORT.
fig-example-path-close illustrates an example of path closing.  In
this case, we are going to close the first path.  For the first path,
the server's 1-RTT packets use DCID C1, which has a sequence number
of 1; the client's 1-RTT packets use DCID S2, which has a sequence
number of 2.  For the second path, the server's 1-RTT packets use
DCID C2, which has a sequence number of 2; the client's 1-RTT packets
use CID S3, which has a sequence number of 3.  Note that two paths
use different packet number space.
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 path immediately.
In Figure fig-example-new-path, the endpoints first exchange new
availabe Connection IDs with the NEW_CONNECTION_ID frame.  In this
exampe the client provides one Connection ID (C1 with sequence number
1), and server provides two Connection IDs (S1 with sequence number
1, and S2 with sequence number 2).
Before the client opens a new path by sending an packet on that path
with a PATH_CHALLENGE frame, it has to check. whether there is an
unused Connection IDs availabe for each side.  In this example the
client chooses the Connection ID S2 as the Destination Connection ID
in the new path.
If the client has used all the allocated CID, it is supposed to
retire those that are not used anymore, and the server is supposed to
provide replacements, as specified in QUIC-TRANSPORT.  Usually it is
desired to proviide one more connection ID as currently in used, to
allow for new paths or migration.
In this example the client detects the network environment change
(client's 4G/Wi-Fi is turned off, Wi-Fi signal is fading to a
threshold, or the quality of RTT or loss rate is becoming worse) and
wants to close the initial path.
In Figure fig-example-path-close the server's 1-RTT packets use DCID
C1, which has a sequence number of 1, for the first path; the
client's 1-RTT packets use DCID S2, which has a sequence number of 2.
For the second path, the server's 1-RTT packets use DCID C2, which
has a sequence number of 2; the client's 1-RTT packets use CID S3,
which has a sequence number of 3.  Note that two paths use different
packet number space.
Thee client initiates the path closure for the path with ID 1 by
sending a packet with an PATH_ABANDON frame.  When the server
reeceived the PATH_ABANDON frame, it also sends an PATH_ABANDON frame
in the next packet.  Afterwards the connection IDs in both directions
can be retired using the RETIRE_CONNECTION_ID frame.
PATH_ABANDON Frame are used by endpoints to inform the peer of the
current status of one path, and the peer should send packets
according to the preference expressed in these frames.  Endpoint use
the sequence number of the CID used by the peer for PATH_ABANDON
frames (describing the sender's path identifier).  PATH_ABANDON
frames are formatted as shown in fig-path-abandon-format.
The PATH_ABANDON frame informs the peer to abandon a path, and
release the corresponding resources.  An endpoint uses the sequence
number of the CID used by the peer for PATH_ABANDON frames
(describing the sender's path identifier).  More complex path
management can be made possible with additional extensions (e.g.,
PATH_STATUS frame in I-D.liu-multipath-quic ).
PATH_ABANDON frames are formatted as shown in fig-path-abandon-
format.
Note: If the receiver of the PATH_ABANDON frame is using non-zero
length Connection ID on that path, endpoint SHOULD use type 0x00 for
path identifier in the control frame.  If the receiver of the
PATH_ABANDON frame is using 0-length Connection ID, but the peer is
using non-zero length Connection ID on that path, endpoints SHOULD
use type 0x01 for path identifier.  If both endpoints are using
0-length Connection IDs on that path, endpoints SHOULD only use type
0x02 for path identifier.
PATH_ABANDON frames can sent on any path, not only the path
identified by the Path Identifier field.
Packet Number Space Identifier: An identifier of the path packet
number space, which is the sequence number of Destination Connection
ID of the 1-RTT packets which are acknowledged by the ACK_MP frame.
If the endpoint receives 1-RTT packets with 0-length Connection ID,
it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.  If
an endpoint receives a ACK_MP frame with a non-existing packet number
space ID, it MUST treat this as a connection error of type
MP_PROTOCOL_VIOLATION and close the connection.
Packet Number Space Identifier: An identifier of the path packet
number space, which is the sequence number of Destination Connection
ID of the 1-RTT packets which are acknowledged by the ACK_MP frame.
If the endpoint receives 1-RTT packets with zero-length Connection
ID, it SHOULD use Packet Number Space Identifier 0 in ACK_MP frames.
If an endpoint receives a ACK_MP frame with a non-existing packet
number space ID, it MUST treat this as a connection error of type
MP_PROTOCOL_VIOLATION and close the connection.
This section lists the defined Multi-path QUIC transport error codes
that can be used in a CONNECTION_CLOSE frame with a type of 0x1c.
These errors apply to the entire connection.
This section lists the defined multipath QUIC transport error codes
that can be used in a CONNECTION_CLOSE frame with a type of 0x1c.
These errors apply to the entire connection.