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

Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328 #705

Merged
merged 4 commits into from Jul 28, 2017
Merged

Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328 #705

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
035573c
Specify RST-like behavior for CONNECTION_CLOSE. Fixes #330, #328
ekr Jul 27, 2017
d38552f
Provide stronger guidance
ekr Jul 28, 2017
ee069a3
Wording
ekr Jul 28, 2017
ac9a77a
Reformat
ekr Jul 28, 2017
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
17 changes: 13 additions & 4 deletions draft-ietf-quic-transport.md
View file
Open in desktop
Expand Up @@ -1441,7 +1441,7 @@ period of time. A QUIC connection, once established, can be terminated in one
of three ways:

1. Explicit Shutdown: An endpoint sends a CONNECTION_CLOSE frame to
initiate a connection termination. An endpoint may send a GOAWAY frame to
terminate the connection. An endpoint may send a GOAWAY frame to
the peer prior to a CONNECTION_CLOSE to indicate that the connection will
soon be terminated. A GOAWAY frame signals to the peer that any active
streams will continue to be processed, but the sender of the GOAWAY will not
Expand Down Expand Up @@ -1469,9 +1469,18 @@ of three ways:
should send a Public Reset packet in return. (TODO: articulate rules around
when a public reset should be sent.)

TODO: Connections that are terminated are added to a TIME_WAIT list at the
server, so as to absorb any straggler packets in the network. Discuss TIME_WAIT
list.
After receiving either a CONNECTION_CLOSE frame or a Public Reset, an
endpoint MUST NOT send additional packets on that connection. After
sending either a CONNECTION_CLOSE frame or a Public Reset packet,
implementations MUST NOT send any non-closing packets on that
connection. If additional packets are received after this time and
before idle_timeout seconds has passed, implementations SHOULD respond
to them by sending a CONNECTION_CLOSE (which MAY just be a duplicate
of the previous CONNECTION_CLOSE packet) but MAY also send a Public
Reset packet. Implementations SHOULD throttle these responses, for
instance by exponentially backing off the number of packets which are
received before sending a response. After this time, implementations
SHOULD respond to unexpected packets with a Public Reset packet.

# Frame Types and Formats

Expand Down