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

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Jan 2020 06:14:31 -0800

At the moment, the recommended way of gracefully shutting down an H3 connection is, according to [section 5.2](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-5.2-7):
> 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. This signals to the client that a shutdown is imminent and that initiating further requests is prohibited._

It is my understanding that the reason we suggest sending "the maximum value allowed by QUIC's MAX_STREAMS" is because, unlike HTTP/2, we cannot send GOAWAY frame with an identifier value that is greater than any possible client-generated bidirectional stream ID.

However, the downside is that the current text assumes tight integration with the QUIC stack that might be unnecessary - let the QUIC stack provide current MAX_STREAMS value, and also stop giving the client new credits.

I am not against the status quo, but I think we might want to give practical advice. The minimum change can be to state "a server that is attempting to gracefully shutdown a connection SHOULD send an Initial GOAWAY frame with the last Stream ID set to the maximum value currently allowed by QUIC's MAX_STREAMS *or any value above that*."

Such change would imply that sending 2<sup>62</sup>-4 (the maximum stream ID for a request stream) assuming that the client would not send that much of requests on a single connection. Note that it is trivial for a server to make sure that the stream ID would not become that big - the server can always gracefully shutdown a connection well before the stream ID becomes that big.

-- 
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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Jan 2020 06:21:55 -0800

PS. The alternative is to change the value carried by the GOAWAY frame from stream ID to "stream ID / 4" (i.e. the value we send using MAX_STREAMS), but IIRC we have rejected that approach, because it is another way of tightly coupling QUICv1 and HTTP/3.

-- 
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-574196347

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jan 2020 15:18:05 -0800

Smells editorial.  @kazuho, do you want to suggest text?

-- 
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-574419493

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 14 Jan 2020 15:39:20 -0800

@martinthomson Thank you for the suggestion. Filed #3343.

-- 
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-574425708

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 Jan 2020 18:49:40 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jan 2020 19:23:47 -0800

I agree with that.  Stacks aren't obligated to offer any option for fine control over MAX_STREAMS, or any means of introspecting into the value.

I would make another change though.  As a suggestion, this text doesn't need normative force.

> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible value (2^62-4 for servers, 2^62-1 for clients).  This ensures that the peer stops creating new requests or pushes.  After allowing time for any in-flight requests (at least one round-trip time), the endpoint can send another GOAWAY frame with an updated value.  In the case that a server does not process some requests, this allows clients to efficiently learn which requests can be retried.

All assuming we go with the suggested outcome of #3129.  Adjust accordingly.

-- 
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-574964216

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 15 Jan 2020 19:41:33 -0800

@martinthomson Thank you for the suggestions. I agree, I've updated #3343 (it's based on master for the time being), I think it now aligns to what you have suggested.

-- 
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-574967930

---

From: Mike Bishop <[email-masked]>
Date: Fri, 17 Jan 2020 12:23:16 -0800

Closed #3341 via #3343.

-- 
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#event-2959390255