Draft: draft-ietf-quic-multipath

Commentary: Since , we now define the Path ID as ( Section 1.1 ) And the definition of the as the field of PATHABANDON and PATHSTATUS frames directly maps to that identifier path ( i.e. , the sequence number of the destination Connection ID used for sending packets on that particular path , Sections 8.1 and 8.2 ) . But in Section 6.2 , the example states that I believe the current text is unclear and should be fixed . Yet , I see two possible ways of doing so . We should either state that the field of these frames refer to the Path ID used by the receiver of the frame , or add some information to indicate that it refers to the Path ID viewed from the sender's / receiver 's viewpoint ( that could be encoded as a bit in the frame 's type ) 
 Is there any use case for either using the sender 's or receiver 's ID ? If not , I 'd prefer we simply choose one and define it clearly . 
 ( P.S. : I think the text in the example is just wrong . I think I messed this up in . ) 
 IMHO it makes more sense to me to use the sender 's ID by default , especially if we consider only client - initiated paths . 
 From PR by 
 Looks good to me
fig-example-path-close1 illustrates an example of path closing.  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 DCID S3, which has a sequence number of 3.  Note
that the paths use different packet number spaces.  In this case, the
client is going to close the first path.  It identifies the path by
the sequence number of the received packet's DCID over that path
(path identifier type 0x00), hence using the path_id 1.  Optionally,
the server confirms the path closure by sending an PATH_ABANDON frame
using the sequence number of the received packet's DCID over that
path (path identifier type 0x00) as path identifier, which
corresponds to the path_id 2.  Both the client and the server can
close the path after receiving the RETIRE_CONNECTION_ID frame for
that path.
fig-example-path-close1 illustrates an example of path closing.  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 DCID S3, which has a sequence number of 3.  Note
that the paths use different packet number spaces.  In this case, the
client is going to close the first path.  It identifies the path by
the sequence number of the received packet's DCID over that path,
hence using the path_id 1.  Optionally, the server confirms the path
closure by sending an PATH_ABANDON frame using the sequence number of
the received packet's DCID over that path as path identifier, which
corresponds to the path_id 2.  Both the client and the server can
close the path after receiving the RETIRE_CONNECTION_ID frame for
that path.
Path Identifier: An identifier of the path, which is formatted as
shown in fig-path-identifier-format.
Identifier Type: Identifier Type field is set to indicate the type
of path identifier.
Type 0: Refer to the connection identifier issued by the sender
of the control frame.  Note that this is the connection
identifier used by the peer when sending packets on the to-be-
closed path.  This method SHOULD be used by default.
Type 1: Refer to the connection identifier issued by the
receiver of the control frame.  Note that this is the
connection identifier used by the sender when sending packets
on the to-be-closed path.
Type 2: Refer to the path over which the control frame is sent
or received.
Path Identifier Content: A variable-length integer specifying the
path identifier.  If Identifier Type is 2, the Path Identifier
Content MUST be empty.
The identifier of the path that should be abandoned.
If the Identifier Type is 0x00 or 0x01, PATH_ABANDON frames MAY be
sent on any path, not only the path identified by the Path Identifier
Content field.  If the Identifier Type if 0x02, the PATH_ABANDON
frame MUST only be sent on the path that is intended to be abandoned.
PATH_ABANDON frames MAY be sent on any path, not only the path
identified by the Packet Number Space Identifier.
Path Identifier: An identifier of the path, which is formatted as
shown in fig-path-identifier-format.  Exactly the same as the
definition of Path Identifier in {#path-abandon-frame}.
Path Status sequence number: A variable-length integer specifying the
sequence number assigned for this PATH_STATUS frame.  The sequence
number MUST be monotonically increasing generated by the sender of
the Path Status frame in the same connection.  The receiver of the
Path Status frame needs to use and compare the sequence numbers
separately for each Path Identifier.
The identifier of the path that the status update correspondes to.
A variable-length integer specifying the sequence number assigned
for this PATH_STATUS frame.  The sequence number MUST be
monotonically increasing generated by the sender of the Path
Status frame in the same connection.  The receiver of the Path
Status frame needs to use and compare the sequence numbers
separately for each Path Identifier.
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 an endpoint receives an ACK_MP frame with a packet number space ID
which was never issued by endpoints (i.e., with a sequence number
larger than the largest one advertised), it MUST treat this as a
connection error of type MP_PROTOCOL_VIOLATION and close the
connection.  If an endpoint receives an ACK_MP frame with a packet
number space ID which is no more active (e.g., retired by a
RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST
ignore the ACK_MP frame without causing a connection error.
The identifier of the path packet number space of the 1-RTT
packets which are acknowledged by the ACK_MP frame.
If an endpoint receives an ACK_MP frame with a packet number space ID
which was never issued by endpoints (i.e., with a sequence number
larger than the largest one advertised), it MUST treat this as a
connection error of type MP_PROTOCOL_VIOLATION and close the
connection.  If an endpoint receives an ACK_MP frame with a packet
number space ID which is no more active (e.g., retired by a
RETIRE_CONNECTION_ID frame or belonging to closed paths), it MUST
ignore the ACK_MP frame without causing a connection error.