Restrict RST to data streams, require replay #274
Conversation
draft-ietf-quic-http.md
Outdated
| be re-played on another message control stream as soon as the maximum number of | ||
| streams permits. If the implementation no longer requires the response to this | ||
| request, it MAY abruptly terminate the corresponding data stream at the same | ||
| time. |
There was a problem hiding this comment.
I think that this is easier to handle with: "If a message control stream is terminated by a RST_STREAM for any reason, an endpoint MUST terminate the connection with a YOU_SCREWED_UP error code." Attempting to rescue the situation isn't worth the effort and aside from exceeding concurrent stream limits during 0-RTT.
I don't think that there is any reason that the transport would legitimately need to close a stream on its own. Even in that case, that should really be done by the application.
There was a problem hiding this comment.
@martinthomson I love the idea of always tearing down, but I'm a bit nervous about the interactions with stream limits and REFUSED streams. You mention 0-RTT in your comment. Is your idea that 0-RTT streams may need to be retried and not result in the connection being closed and might have to do a retry dance?
There was a problem hiding this comment.
Anyone who exceeds a stream limit is violating the protocol (we need to address the issue of squishiness in that limit). And refusing a stream is easy: refuse the data stream. If the concern is that headers will consume stream limit until they resolve, I think that's a feature, not a bug.
0-RTT streams that end up exceeding some server limit can be refused by hitting the data stream. The control stream can be left to run to completion. If the server can't handle that (because the limits have been reduced by more than 50% perhaps), then it probably should reject 0-RTT.
A server might have to reject the connection (after all, it might only discover this sort of dire condition after foolishly/optimistically accepting 0-RTT), but that means that a new connection will have to created by the client. Mike already has text about needing to retry in #236. In the end, I think that sort of retry is something clients that attempt 0-RTT will just have to deal with.
There was a problem hiding this comment.
I think the concern is that the transport layer doesn't necessarily know what's a data stream versus a control stream. And if the application layer has said "Give me no more than 10 streams at a time," it seems... odd for the QUIC layer to then say "Here are 20 streams that have just arrived; if you'd like to shoot 10 of them, feel free." The app already set the limit, and that limit should be enforced.
And if that enforcement causes the whole connection to get torn down, that might be okay.
There was a problem hiding this comment.
That's right. Though 0-RTT is a complication. An application that enables 0-RTT has to be prepared to accept more than its current limit. That is, up to its previously advertised limit or the defaults, whichever is greater (damn, I still think that's an awful decision).
Outside of that, I think the goal should be that if the limit is exceeded, it should be punished with immediate termination of the connection. The transport can enforce that easily enough.
|
This covers the non-0-RTT case. The text on retrying if 0-RTT fails should cover this form of failure as well, though that's a little pathological. Are we okay to merge? |
Fixes #176, but I'm hoping we can find a cleaner way to do this.