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

GOAWAY means no more #3338

Merged
merged 5 commits into from Jan 15, 2020
Merged

GOAWAY means no more #3338

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
9dc92e4
GOAWAY means no more, like H2
MikeBishop Jan 13, 2020
6733c87
Clarify the prohibition
MikeBishop Jan 13, 2020
199b309
Wordsmith
MikeBishop Jan 13, 2020
6cc93ff
Use 'GOAWAY frame' consistently
MikeBishop Jan 14, 2020
8c86dfe
Clarify previously-promised
MikeBishop Jan 14, 2020
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
29 changes: 15 additions & 14 deletions draft-ietf-quic-http.md
View file
Open in desktop
Expand Up @@ -691,23 +691,24 @@ ID. Requests or pushes with the indicated identifier or greater are rejected by
the sender of the GOAWAY. This identifier MAY be zero if no requests or pushes
were processed.

The information in the GOAWAY enables a client and server to agree on which
requests or pushes were accepted prior to the connection shutdown. Endpoints
SHOULD abruptly terminate any requests or pushes that have identifiers greater
than or equal to the smallest identifier sent in a GOAWAY frame.
The information in the GOAWAY frame enables a client and server to agree on
which requests or pushes were accepted prior to the connection shutdown.
Endpoints SHOULD abruptly terminate any requests or pushes that have identifiers
greater than or equal to the smallest identifier sent in a GOAWAY frame.

Endpoints MUST NOT initiate new requests or pushes on the connection with an
identifier greater than or equal to the smallest identifier received in a GOAWAY
frame. Clients MAY establish a new connection to send additional requests.
Endpoints MUST NOT initiate new requests or promise new pushes on the connection
after receipt of a GOAWAY frame from the peer. Clients MAY establish a new
connection to send additional requests.

Some requests or pushes might already be in transit. If the endpoint has already
sent requests or pushes with an identifier greater than or equal to that
received in a GOAWAY frame, those requests or pushes will not be processed;
sent requests or promised pushes with an identifier greater than or equal to
that received in a GOAWAY frame, those requests or pushes will not be processed;
requests MAY be retried by the client on a different connection. The endpoint
that initiated these requests or pushes MAY cancel them. It is RECOMMENDED that
the receiving endpoint explicitly reject such requests (see
{{request-cancellation}}) or pushes (see {{frame-cancel-push}}) in order to
clean up transport state for the affected streams.
clean up transport state for the affected streams. Pushes which have been
promised MAY still be fulfilled by the server.

Requests on Stream IDs less than the Stream ID in a GOAWAY frame from the server
might have been processed; their status cannot be known until a response is
Expand Down Expand Up @@ -738,8 +739,8 @@ ensures that a connection can be cleanly shut down without losing requests.

A client has more flexibility in the value it chooses for the Push ID in a
GOAWAY that it sends. A value of 2^62 - 1 indicates that the server can
continue initiating pushes to complete outstanding requests, and the client can
continue granting push credit as needed (see {{frame-max-push-id}}). A smaller
continue fulfilling pushes which have already been promised, and the client can
continue granting push credit as needed (see {{frame-max-push-id}}). A smaller
value indicates the client will reject pushes with Push IDs greater than or
equal to this value. Like the server, the client MAY send subsequent GOAWAY
frames so long as the specified Push ID is strictly smaller than all previously
Expand All @@ -761,8 +762,8 @@ This results in sending a QUIC CONNECTION_CLOSE frame to the peer; the error
code in this frame indicates to the peer why the connection is being closed.
See {{errors}} for error codes which can be used when closing a connection.

Before closing the connection, a GOAWAY MAY be sent to allow the client to retry
some requests. Including the GOAWAY frame in the same packet as the QUIC
Before closing the connection, a GOAWAY frame MAY be sent to allow the client to
retry some requests. Including the GOAWAY frame in the same packet as the QUIC
CONNECTION_CLOSE frame improves the chances of the frame being received by
clients.
Comment on lines +765 to 768
Copy link
Member

Choose a reason for hiding this comment

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

With the parallel changes and discussion around GOAWAY I'm really struggling to understand the suggestion of including the GOAWAY frame in the same packet as the QUIC CONNECTION_CLOSE

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the text is suggesting that if they are in different packets and the CONNECTION_CLOSE arrives first, then the GOAWAY might be ignored?

Copy link
Contributor

@ianswett ianswett Jan 15, 2020 •
edited

Choose a reason for hiding this comment

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

The intent is: If a client receives a GOAWAY first, it knows what requests it can retry, hence the value of putting both frames in a single packet.

Copy link
Member

Choose a reason for hiding this comment

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

We're mixing together processing of a QUIC frame and an application-layer frame delivered inside of STREAM frames. I'm not sure trying to make assertions on the ordering of those things is the best way to do it. My I should open this out as a separate issue.

Copy link
Member

Choose a reason for hiding this comment

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

What if they are in the same packet but the STREAM frame comes after the CONNECTION_CLOSE?

Copy link
Contributor

Choose a reason for hiding this comment

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

Then likely the CONNECTION_CLOSE will be processed before the GOAWAY and the receiver will process the CONNECTION_CLOSE and ignore the GOAWAY. I think that's how this has to work, but maybe I'm wrong?

Copy link
Member

Choose a reason for hiding this comment

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

I think you're right. Thinking some more, I think the phrasing could be read to say that inclusion improves the probability of delivery, which is odd. When actually what it is trying to articulate is that processing order has some importance. However, just because the data arrives at the same point in time doesn't mean much IMO, that GOAWAY frame could just as well be blocked by other stuff waiting to be restransmitted on the stream.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Admittedly, it's best effort. This also implies that there might be value in permitting the application layer to drain whatever data has arrived, even if a CONNECTION_CLOSE has also been received.


Expand Down