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

Kazuho Oku <notifications@github.com> Thu, 16 January 2020 02:49 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF53D120855 for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 18:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.739
X-Spam-Level:
X-Spam-Status: No, score=-7.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytWnYRe5v9Qc for <quic-issues@ietfa.amsl.com>; Wed, 15 Jan 2020 18:49:40 -0800 (PST)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03BD12002F for <quic-issues@ietf.org>; Wed, 15 Jan 2020 18:49:40 -0800 (PST)
Date: Wed, 15 Jan 2020 18:49:40 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1579142980; bh=so2oW4DC9lcFn/ifeO4ktgaCO8PvQf4H4y8BU/fzVK0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OZNtuO2dGV0dNTCSL/+kaaKBPTfkCt1oMnbIekuIbiNK0tIgEkuMgGsTqff/F5Z+Y X5q7LdmqK+2SCrsYXj//wxtqtnqN+wJy7YKEmUk7Pa4oauI5EjXGPmgUD7qeiatPVH NLLvtcGxo9c2yqjt8fOlJ8o+HjRZYvjMVCdC7vzs=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2RCX3OP6OWZIOIO4F4FUA4JEVBNHHCBQRINU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3341/574956848@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3341@github.com>
References: <quicwg/base-drafts/issues/3341@github.com>
Subject: Re: [quicwg/base-drafts] suggest easier way of initiating graceful shutdown from the server-side (#3341)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e1fcf442557a_2ad93f9b074cd95c47280"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/wHzDRRDYxoNhgHlqUNwUzOqOsiw>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Jan 2020 02:49:43 -0000

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