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

Jump to bottom

editorial changes in the closing section #2315

Closed
wants to merge 3 commits into from
Closed

editorial changes in the closing section #2315

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9459331
remove misleading sentence about closing and stateless resets
marten-seemann Jan 8, 2019
0078d2d
allow closing and draining periods longer than 3 PTO
marten-seemann Jan 8, 2019
1732dd9
editorial changes in the closing section
marten-seemann Jan 8, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
18 changes: 8 additions & 10 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -2187,18 +2187,19 @@ of three ways:

The closing and draining connection states exist to ensure that connections
close cleanly and that delayed or reordered packets are properly discarded.
These states SHOULD persist for three times the current Probe Timeout (PTO)
interval as defined in {{QUIC-RECOVERY}}.
These states SHOULD persist for at least three times the current Probe Timeout
(PTO) interval as defined in {{QUIC-RECOVERY}}.

An endpoint enters a closing period after initiating an immediate close
({{immediate-close}}). While closing, an endpoint MUST NOT send packets unless
they contain a CONNECTION_CLOSE frame (see {{immediate-close}} for details). An
endpoint retains only enough information to generate a packet containing a
CONNECTION_CLOSE frame and to identify packets as belonging to the connection.
The connection ID and QUIC version is sufficient information to identify packets
for a closing connection; an endpoint can discard all other connection state.
An endpoint MAY retain packet protection keys for incoming packets to allow it
to read and process a CONNECTION_CLOSE frame.
The source and the destination connection ID and the QUIC version are sufficient
Copy link
Contributor

Choose a reason for hiding this comment

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

If it's possible the source CID could change, I'd suggest we only mention the destination CID.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It looks like we have different scenarios in mind. I was thinking about an error that occurs during the handshake. In that case, you close the connection, but there might still be Handshake packets arriving, which you would want to ignore then.
You seem to be thinking about the peer switching to a new connection ID. If we want to cover that case, it seems like we need to remember all connection IDs that are still active.

Copy link
Member

Choose a reason for hiding this comment

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

The intent here was destination connection ID. That should always be sufficient to identify the connection. The source connection ID doesn't appear on any packets that are likely to matter and it only matters for the purposes of generating these packets.

Source connection ID might matter for the first Initial packet from the client, where there might be some value in distinguishing between connection attempts with colliding destination connection IDs. The odds of that are slim enough for this to not matter though.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We're talking from the view point of a connection here, so the CID that's necessary to assign a packet is one of the source CIDs (which will be the destination CID of the incoming packet).
You'll need to remember at least one of the destination CIDs for the connection ID in order to repeat the CONNECTION_CLOSE frame in the closing state.

Copy link
Member

Choose a reason for hiding this comment

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

I don't know what people view as source and destination when not talking about packets. That's not something we have crisp terms for, but using source and destination here makes that problem worse.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just talking about "connection ID" is insufficient though, since I need to remember at least the connection ID I'm receiving packets at (which I would have called my source), and one connection ID I'm sending packets to (which I would have called my destination).
In addition, depending on how frequently the peer switches to new connection IDs, I maybe should also remember the outstanding connection IDs I've issued to my peer.

Copy link
Member

Choose a reason for hiding this comment

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

This text is specifically talking about identifying incoming packets, so the only connection ID that is relevant is the inbound one. The final sentence of the paragraph is where the outbound connection ID becomes relevant.

information to identify packets for a closing connection; an endpoint can
discard all other connection state. An endpoint MAY retain packet protection
keys for incoming packets to allow it to read and process a CONNECTION_CLOSE
frame.

The draining state is entered once an endpoint receives a signal that its peer
is closing or draining. While otherwise identical to the closing state, an
Expand All @@ -2225,14 +2226,11 @@ connection state. This results in new packets on the connection being handled
generically. For instance, an endpoint MAY send a stateless reset in response
to any further incoming packets.

The draining and closing periods do not apply when a stateless reset
({{stateless-reset}}) is sent.

Copy link
Member

Choose a reason for hiding this comment

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

What do you hope to achieve by removing this text? It's still accurate, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Closing and draining applies to connections. Stateless reset is sent when there is no connection, so I have no idea how this sentence would apply.

Copy link
Member

Choose a reason for hiding this comment

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

That is the whole point of the text. You could expand it to say that this is because there is no connection, I suppose.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As it stands, it sounds like instead of going through draining and closing period, I can choose a shortcut and just send a stateless reset to kill a connection. I have no idea how one would even start the closing period if there was no connection in the first place.

An endpoint is not expected to handle key updates when it is closing or
draining. A key update might prevent the endpoint from moving from the closing
state to draining, but it otherwise has no impact.

While in the closing period, an endpoint could receive packets from a new source
While in the closing period, a server could receive packets from a new source
address, indicating a client connection migration ({{migration}}). An endpoint
Copy link
Member

Choose a reason for hiding this comment

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

We've generally avoided assigning roles, preferring to talk about migration as valid in both directions, so it might be better to say endpoint/peer rather than server/client here. That doesn't matter though.

in the closing state MUST strictly limit the number of packets it sends to this
new address until the address is validated (see {{migrate-validate}}). A server
Expand Down