-
Notifications
You must be signed in to change notification settings - Fork 204
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.
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
GOAWAY needs a maximum stream number in both directions #354
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally looks good. I agree, this is bugfix-level.
draft-ietf-quic-transport.md
Outdated
|
||
: The last client-initiated Stream ID which was accepted by the sender of the | ||
GOAWAY frame. All higher-numbered, client-initiated streams (that is, odd | ||
numbered streams) are implicitly reset by sending or receiving the GOAWAY |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: "even-numbered" and "odd-numbered" should be hyphenated.
From the commit comment: I have also added text that captures something we learned late in the HTTP/2 experience. GOAWAY pre-emptively closes streams, but for peer-initiated streams it might make sense to use a bigger number to allow any requests that the peer created in the last round trip to complete. Some implementations find retrying quite difficult and allowing (for example) a client's last set of requests to complete can make the shutdown properly graceful (as opposed to toy-graceful). The case where this matters is for a gateway to server, where the gateway can't reasonably retry the 10,000 requests that it initiated in the last second. To allow for that, the server can give the gateway a bit of extra leeway for those streams when it sends a GOAWAY frame. |
Sorry if that's a little bit off topic but at this point I'm actually wondering if GOAWAY is really part of the transport semantics or should be an application layer signal...? |
@mirjak, I can't actually think of a strong reason why GOAWAY has to be a transport concept. The ideas I came up with are:
In other words, yeah, we can make this an application-layer concern. |
I have also taken the liberty of making the text that matches this more directly applicable.
I have also added text that captures something we learned late in the HTTP/2 experience. GOAWAY pre-emptively closes streams, but for peer-initiated streams it might make sense to use a bigger number to allow any requests that the peer created in the last round trip to complete. Some implementations find retrying quite difficult and allowing (for example) a client's last set of requests to complete can make the shutdown properly graceful (as opposed to toy-graceful). The case where this matters is for a gateway to server, where the gateway can't reasonably retry the 10,000 requests that it initiated in the last second. To allow for that, the server can give the gateway a bit of extra leeway for those streams when it sends a GOAWAY frame.
4faa537
to
2c716f8
Compare
I'm dubious that we'll land text on application-level clean shutdown before the draft deadline. Let's merge this bugfix for consistency in -02, then start on that change separately. If I'm wrong and we can close on it quickly, great! |
I have also taken the liberty of updating the text that surrounds the frame type.
@janaiyengar, @mnot, @larseggert, I believe that this is basically a bugfix and it doesn't need any more discussion that it has already. If you disagree, then we'll hold off on merging until we've had more discussion.
Closes #347.