Draft: draft-lmbdhk-quic-multipath

Commentary: Mostly to fix presentation / grammar issues , also merging section Path Validation / Path Initiation as this seems to be the same process . 
 We need some description for how to init new paths in this section . 
 To me path validation and path initiation are very coupled together . In I merged both sections together . 
 That 's probably fine . I was keeping this as a placeholder in case we need anything in addition but probably not . 
 It 's ok . 
 Thanks for all the text correction ! It 's ok for me .
A path is determined by the 4-tuple of source and destination IP
address as well as source and destination port.  Therefore there
can at maximum be one active paths/connection ID per 4-tuple.
A path is determined by the 4-tuple of source and destination IP
address as well as source and destination port.  Therefore there
can be at most one active paths/connection ID per 4-tuple.
Continue using an existing path even if non probing frames have
been received on another frame.
As such this extension is specifying a departure from the
specification of path management in section 9 of QUIC-TRANSPORT and
therefore requires negotiation between the two endpoints using a new
transport parameter, as specified in nego.
This proposal supports the negotiation of the use of either 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 require the use of a connection ID.
Therefore both approaches support different use cases as a single
number space can be beneficial in highly constraint 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.
Continue using an existing path even if non-probing frames have
been received on another path.
As such this extension specifies a departure from the specification
of path management in section 9 of QUIC-TRANSPORT and therefore
requires negotiation between the two endpoints using a new transport
parameter, as specified in nego.
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.
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT with single path and MUST NOT use any MP
frames or mechanism defined in this document.
If the peer does not carry the enable_multipath transport parameter,
which means the peer does not support multipath, endpoint MUST
fallback to QUIC-TRANSPORT with single path and MUST NOT use any
frame or mechanism defined in this document.
After endpoints have negotiated in handshake flow that both endpoints
enable multipath feature, endpoints can start using multiple paths.
All the new MP frames are sent in 1-RTT packets QUIC-TRANSPORT.
After completing the handshake and endpoints have agreed to enable
multipath feature, endpoints can start using multiple paths.
All the new frames are sent in 1-RTT packets QUIC-TRANSPORT.
Both client and server can close a path, by sending PATH_STATUS frame
which abandons the path with a corresponding Path Identifier.  Once a
path is marked as "abandon", it means that the resources related to
the path can be released.
Both client and server can close a path, by sending PATH_STATUS 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.
The simultaneous usage of several sending uniflows introduces new
algorithms (packet scheduling, path management) whose specifications
are out of scope of this document.  Nevertheless, these algorithms
are actually present in any multipath-enabled transport protocol like
Multipath TCP, CMT-SCTP and Multipath DCCP.  A companion draft I-
D.bonaventure-iccrg-schedulers provides several general-purpose
packet schedulers depending on the application goals.  A similar
document can be created to discuss path/uniflow management
considerations.
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 1RTT packets while the state
of multipath negotiation is ambiguous, they MUST be interpreted as
acknowledging packets sent on path number 0.
If endpoints negotiate multipath support with value 1 to use multiple
packet number space, they SHOULD use ACK_MP frames instead of ACK
frames to signal acknowledgement of 1-RTT packets, and also 0-RTT
packets as specified in handling-of-0-rtt-packets.
All 0-RTT packet 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
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 0".
The simultaneous usage of several sending uniflows introduces new
algorithms (packet scheduling, path management) whose specifications
are out of scope of this document.  Nevertheless, these algorithms
are actually present in any multipath-enabled transport protocol like
Multipath TCP, CMT-SCTP and Multipath DCCP.  A companion draft I-
D.bonaventure-iccrg-schedulers provides several general-purpose
packet schedulers depending on the application goals.  A similar
document can be created to discuss path management considerations.
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.
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".
If one common packet number space is used for all path, 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.
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.
Packet loss detection MUST be adapted to allow for different RTT 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.
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.
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 experience 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.
If timestamps are not available, implementations could estimate one
way delays using statistical techniques.  For example, in the example
shown in Table 1, implementations can use use "same path"
measurements to estimate the one way delay of the terrestrial path to
about 50ms in each direction, and that of the satellite path to about
300ms.  Further measurements can then be used to maintain estimates
of one way delay variations, using logical similar to Kalman filters.
But statistical processing is error rone, and using time stamps
provides more robust measurements.
If timestamps are not available, implementations could estimate one
way delays using statistical techniques.  For example, in the example
shown in Table 1, implementations can use use "same path"
measurements to estimate the one way delay of the terrestrial path to
about 50ms in each direction, and that of the satellite path to about
300ms.  Further measurements can then be used to maintain estimates
of one way delay variations, using logical similar to Kalman filters.
But statistical processing is error-prone, and using time stamps
provides more robust measurements.
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 connection ID in these packets.
Note: Even if 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 find 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 claim usable connections IDs for itself.  Before an endpoint adds
a new path, it SHOULD check whether there is at least one unused
available Connection ID for each side.
If the transport parameter "active_connection_id_limit" is negotiated
as N, and the server provides N Connection IDs.  If the client is
already actively using N paths, the limit is reached.  If the client
wants to start a new path, it has to retire one of the established
paths.
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 SHOULD check whether there is at least one unused
available Connection ID for each side.
If the transport parameter "active_connection_id_limit" is negotiated
as N, the server provided N Connection IDs, and the client is already
actively using N paths, the limit is reached.  If the client wants to
start a new path, it has to retire one of the established paths.
of QUIC-TRANSPORT encode this Connection ID Sequence Number as a 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.
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.
fig-example-new-path illustrates an example of new path
establishment.
fig-example-new-path illustrates an example of new path establishment
using multiple packet number spaces.
If an endpoint receives MP frames from packets of other encryption
levels, it MUST return MP_PROTOCOL_VIOLATION as a connection error
and close the connection.
If an endpoint receives multipath-specific frames from packets of
other encryption levels, it MUST return MP_PROTOCOL_VIOLATION as a
connection error and close the connection.
If the value of Path Status field is 2-available, the receiver side
can use the Path Priority field to express the priority weight of a
path for the peer.
If the value of Path Status field is 2 ("available"), the receiver
side can use the Path Priority field to express the priority weight
of a path for the peer.
This document defines a new transport parameter for the negotiation
of enable multiple paths for QUIC, and three new frame types.  The
draft defines provisional values for experiments, but we expect IANA
to allocate short values if the draft is approved.
This document defines a new transport parameter for the negotiation
of enable multiple paths for QUIC, and two new frame types.  The
draft defines provisional values for experiments, but we expect IANA
to allocate short values if the draft is approved.