Draft: draft-lmbdhk-quic-multipath

Commentary: Simplify pathstatus frame with   following the discussion on issue . Error code and   are left TBD . 
 I actually think we should have keep stand - by . I think this was useful in MPTCP and it 's not really related to scheduling . Stand - by only means : I wo n't use this path but please keep it open . 
 The current draft says " Servers SHOULD stop sending traffic on paths through which non - probing packet was received in the last 3 path RTTs , but MAY ignore that rule if it would disqualify all available paths " . First , I believe there is a typo , where the " non - probing packet " should be " no non - probing packet " . Second , 3 RTT is too short for our applications and we prefer a longer timeout . Maybe we want to add a new parameter ( e.g. maxpathidle_timeout ) to allow the server and client to negotiate ? 
 I fixed the missing no . I took this text from Christian 's draft . So maybe he can comment . ? 
 I would suggest to leave the path closing problem for further work and indicate that the next version of the draft will define how a path can be closed by one of the endpoints . 
 There are two issues , path closing and packet scheduling . For path closing , the simplest solution is to use an idle timer , either the idle timer negotiated for the connection or a new parameter negotiated as part of multipath setup . For packet scheduling , the first rule is to not send data on paths that do not work , e.g. , lots of packet losses , or maybe absence of ACK . This is basically the same issue as determining whether a connection is broken , just applied to a path . But that is not entirely sufficient , because the server needs to also infer whether the client still wants to use that path . The monitoring of non probing packets is just an heuristic . The server observes that if the client is not using the path , and deduces that it should not be using it itself . That 's not a bad heuristic , but it requires the client to send some kinds of " keep alive " if it wants the server to continue using a path . We may debate how often that should happen . Maybe reuse the same timeout as for jettisoning paths . Another solution may be for the client to tell something like " please do n't use that path anymore " , but that requires adding a new frame as part of the core multipath specification . In draft - liu , this was done with a specialization of the " path status " , setting the status to " Abandon " . Maybe we should just use a simplified for of the PATH_STATUS , leaving out the complexities of managing priorities for the advanced scheduling drafts : 
 I prefer the second approach that Christian proposed , i.e. , sending explicit signals like " abandon " . But there is an issue with path i d type 0x02 in the current draft , which refers to the path over which the control frame is sent or received . The current draft says " If both endpoints are using 0 - length Connection IDs on that path , endpoints SHOULD only use type 0x02 for path identifier " , so in this case , if a path is broken , we can not send an explicit " abandon " signal for that path thru other paths , and we have to rely on implicit signals like an idle timeout . That means we may still want to negotiate the idle timer ? 
 The client can always force the issue by dropping all packets received on an old path . They will not be acknowledged , and the server will automatically deduce that the path does not work . Of course , that is ugly ... 
 Note that the " Abandon Path " would be a replacement or a simplification of the " Path Status " frame in the current draft . In my code , I only use the " Abandon " variant of the Path Status . I wonder whether we need alternative statuses like " standby " , and whether we should define priorities here , rather than in a separate draft for advanced scheduling . 
 Yes , I agree . We should put the alternative statuses and priority in a separate draft on advanced scheduling . 
 I submitted PR on this issue . 
 This PR was merged . 
 Look good to me . I made a typo , see comment on closing this path . Apart from that , looks good .
Path Identifier (Path ID): An identifier that is used to identify
a path in a QUIC connection at an endpoint.  Path Identifier is
used in multi-path control frames (etc.  PATH_STATUS frame) to
identify a path.  By default, it is defined as the sequence number
of the destination Connection ID used for sending packets on that
particular path, but alternative definitions can be used if the
length of that connection ID is zero.
Path Identifier (Path ID): An identifier that is used to identify
a path in a QUIC connection at an endpoint.  Path Identifier is
used in multi-path control frames (etc.  PATH_ABANDON frame) to
identify a path.  By default, it is defined as the sequence number
of the destination Connection ID used for sending packets on that
particular path, but alternative definitions can be used if the
length of that connection ID is zero.
An endpoint uses PATH_STATUS frames to inform that the peer should
send packets in the preference expressed by these frames.  An
endpoint uses the sequence number of the CID used by the peer for
PATH_STATUS frames (describing the sender's path identifier).
Abandon a path, and release the corresponding resource.
Mark a path as "available", i.e., allow the peer to use its own
logic to split traffic among available paths.
Mark a path as "standby", i.e., suggest that no traffic should be
sent on that path if another path is available.
Mark the priority of a path, i.e, path 1 is weight 8, path 2 is
weight 2, suggest that path 1 has higher priority than path 2, and
peer should try to send more data in path 1.
PATH_STATUS frame can be sent on any path, not only the path
identified by the Path Identifier field.
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.
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_STATUS frame.
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.
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.
In this example, if the client wants to send a PATH_STATUS frame to
tell the server that it prefers the path with CID sequence number 1
(of the server's side), the client should use the identifier of the
server (sequence 1) in PATH_STATUS frame.
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.
PATH_STATUS 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_STATUS
frames (describing the sender's path identifier).  PATH_STATUS frames
are formatted as shown in fig-path-status-format.
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.
Note: If the receiver of the PATH_STATUS 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_STATUS 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 Status sequence number: A variable-length integer specifying the
sequence number assigned for this PATH_STATUS frame.  There is a
different path status sequence number space for each path.
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.
Frames may be received out of order.  A peer MUST ignore an incoming
PATH_STATUS frame if it previously received another PATH_STATUS frame
for the same Path Identifier with a sequence number equal to or
higher than the sequence number of the incoming frame.
PATH_STATUS frames SHOULD be acknowledged.  If a packet containing a
PATH_STATUS frame is considered lost, the peer should only repeat it
if it was the last status sent for that path - as indicated by the
sequence number.
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.
A variable-length integer that indicates the reason for abandoning
this path.
A variable-length integer specifying the length of the reason
phrase in bytes.  Because an PATH_ABANDON frame cannot be split
between packets, any limits on packet size will also limit the
space available for a reason phrase.
Additional diagnostic information for the closure.  This can be
zero length if the sender chooses not to give details beyond the
Error Code value.  This SHOULD be a UTF-8 encoded string RFC3629,
though the frame does not carry information, such as language
tags, that would aid comprehension by any entity other than the
one that created the text.
PATH_ABANDON frames SHOULD be acknowledged.  If a packet containing a
PATH_ABANDON frame is considered lost, the peer should repeat it.