Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarifications on PATH_ABANDON #46

Merged
merged 4 commits into from
Oct 25, 2021
Merged

Clarifications on PATH_ABANDON #46

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
2d878bf
Clarifications on PATH_ABANDON
mirjak Oct 25, 2021
3bddf29
Update draft-lmbdhk-quic-multipath.md
mirjak Oct 25, 2021
8f13055
Apply suggestions from code review
mirjak Oct 25, 2021
cc686c0
Apply suggestions from code review by qdeconinck
mirjak Oct 25, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 39 additions & 6 deletions draft-lmbdhk-quic-multipath.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,7 @@ 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
local preferences. After an endpoint abandons a path, the peer 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,
Expand All @@ -199,7 +199,40 @@ but instead SHOULD use explicit request to terminate path by sending the PATH_AB

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.
as "abandoned", it means that the resources related to the path, such as the used connection IDs, can be released.
However, information related to data delivered over that path SHOULD not be released immediately
as ACK can still be received on other frame that also my trigger retransmission of data on another path.
mirjak marked this conversation as resolved.
Show resolved Hide resolved

The endpoint sending the PATH_ABANDON frame SHOULD consider a path as abandoned when the ACK for the
packet that contained the PATH_ABANDON frame was received. When releasing resources of a path,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"when the packet that contained the PATH_ABANDON frame got acknowledged"

mirjak marked this conversation as resolved.
Show resolved Hide resolved
the endpoint SHOULD send a RETIRE_CONNECTION_ID frame for the connection IDs used on the path, if any.

The receiver of a PATH_ABANDON frame SHOULD NOT release its resources immediately but SHOULD
wait for the receive of the RETIRE_CONNECTION_ID frame for the used connection IDs or 3 RTOs.

Usually it is expected that the PATH_ABANDON frame is used by the client to indicate to the server
that path conditions have changed such that the path is or will be not usable anymore, e.g. in case
of an mobility event. The PATH_ABANDON frame therefore indicates to the receiving peer that the sender
does not intent to send any packets on that path anymore but also recommends to the receiver that no
mirjak marked this conversation as resolved.
Show resolved Hide resolved
packets should be sent in either direction. The receiver of an PATH_ABANDON frame MAY also
send an PATH_ABANDON frame to signal its own willingness to not send any packet on this path anymore.

If connection IDs are used, PATH_ABANDON frames can be sent on any path, not only the path that
is intended to be closed. Thus a connection can be abandoned even if connectivity on that path is
already broken. If no connection IDs are used and the PATH_ABANDON frame has to sent on the path
that is intended to be closed, it is possible that the packet containing the PATH_ABANDON frame or
the packet containing the ACK for the PATH_ABANDON frame cannot the received anymore and the endpoint
mirjak marked this conversation as resolved.
Show resolved Hide resolved
might need to rely on an idle time out to close the path, as described in Section {{idle-time-close}}.

Packets, that have previously been send on the abandoned path and are considered lost, SHOULD be
retransmitted on a different path.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would precise that the retransmittable frames (or content) of these packets should be retransmitted

mirjak marked this conversation as resolved.
Show resolved Hide resolved

Copy link
Collaborator Author

@mirjak mirjak Oct 25, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If an endpoint wants to close the last open path of a connection, it MUST use the CONNECTION_CLOSE frame as specified in {{RFC9000}}.

If a PATH_ABANDON frame is received for the only active path of a QUIC connection, the receiving
peer SHOULD send a CONNECTION_CLOSE frame and enters the closing state. If the client
received a PATH_ABANDON frame for the last open path, it MAY instead try to open a new path, if
available, and only initiate connection closure if path validation fails or a CONNECTION_CLOSE frame
is received from the server. Similarly the server MAY wait for a short, limited time such as one RTO
if a path probing packet is received on a new path before sending the CONNECTION_CLOSE frame.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it be more clear that the endpoint just use CONNECTION_CLOSE frame immediately if the endpoint don't want to use the last path?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's what the client/sender should do. However this text is discussing what happens if you received a PATH_ABANDON on the last open path despite.

We could consider this as a protocol violation, however, as two PATH_ABANDON frames for each end could cross each other if both ends are allow to send PATH_ABANDON, I don't think it should be a protocol violation.

We could add one more sentence that usually CONNECTION_CLOSE should be used to close the last open path.


### Effect of RETIRE_CONNECTION_ID Frame

Expand All @@ -209,7 +242,7 @@ this endpoint, the resources include the list of received packets used to send a
The peer MAY decide to keep sending data using the same IP addresses and UDP ports previously
associated with the connection ID, but MUST use a different connection ID when doing so.

### Idle Timeout
### Idle Timeout {#idle-time-close}

{{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
Expand Down Expand Up @@ -555,7 +588,7 @@ MP_PROTOCOL_VIOLATION as a connection error and close the connection.
## PATH_ABANDON Frame {#path-abandon-frame}

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
path. 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
Expand Down Expand Up @@ -620,9 +653,9 @@ Reason Phrase:
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.
frame is considered lost, the peer SHOULD repeat it.

PATH_ABANDON frames can sent on any path, not only the path identified by the
PATH_ABANDON frames MAY be sent on any path, not only the path identified by the
Path Identifier field.


Expand Down