Re: [quicwg/base-drafts] suggest easier way of initiating graceful shutdown from the server-side (#3341)

[Kazuho Oku <[e-mail]>]

In https://github.com/quicwg/base-drafts/pull/3343#discussion_r367154672, @martinthomson points out that we can drop the recommendation to stop sending MAX_STREAMS once the server sends the first GOAWAY.

Reading his comment, I now think that it might be better simply stop recommending the server sending GOAWAY with last Stream ID set to the current maximum, and instead recommend sending 2<sup>62</sup> - 4 (the theoretical maximum). Even if such a change makes this issue a design issue.

Let me explain why.

Quoting from [section 5.2](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-5.2-7), the status quo is:
> A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last Stream ID set to the maximum value allowed by QUIC's MAX_STREAMS and SHOULD NOT increase the MAX_STREAMS limit thereafter.

People might (or would) read that the second SHOULD is merely a recommendation, and consider that just send GOAWAY with last Stream ID set to the current maximum is okay.

The reality is that it is not. This is because there is no guarantee that the GOAWAY frame reaches the client before a MAX_STREAMS frame that the QUIC stack might generate reaches the client.

Therefore, if the server is to send a GOAWAY frame with last Stream ID set to the current maximum, it MUST stop sending MAX_STREAMS that grant additional concurrency credit.

However, as @martinthomson points out, such requirement is not necessary in terms of gracefully shutting down the connection. Just sending GOAWAY with last Stream ID set to 2<sup>62</sup>-4 is sufficient.

Considering that, I think just recommending 2<sup>62</sup>-4 is the best way forward.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3341#issuecomment-574956848