Re: [quicwg/base-drafts] H3 GOAWAY should be symmetric and cover bidi and uni streams (#2632)

Lucas Pardue <> Thu, 18 April 2019 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 800D8120340 for <>; Thu, 18 Apr 2019 06:55:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.001
X-Spam-Status: No, score=-8.001 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d8tO_QtVKB7Z for <>; Thu, 18 Apr 2019 06:55:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B5A612014A for <>; Thu, 18 Apr 2019 06:55:48 -0700 (PDT)
Date: Thu, 18 Apr 2019 06:55:47 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1555595747; bh=kIOt8ndWNPkigzAY4QkXGxVeJOuH8Y2u+5zZLH9LRlA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bBl13cUxhYn9m7nFQPZW5S1xiXoN6yaZwAFxvkgl4RAQz6xzyj4IFOgadinKnJSIu MhOe8mWMsSoWkSLMcESS7Bk6eCSfA3zFbXjSkPDIw2fBAv44DB9E9PqYkIBGAXrng3 1NYQ1CdeJGoWfjRfzbSKpeDVH23puChhrmf4fT6s=
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2632/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] H3 GOAWAY should be symmetric and cover bidi and uni streams (#2632)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cb881e346c0_1a613fab5e8cd9641209b3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: LPardue
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Apr 2019 13:55:51 -0000

> I think this argument makes sense, but this feels increasingly like a transport feature and not an HTTP feature.

I don't have a strong opinion here. For reference, the original issue about moving GOAWAY out of transport is

For the separate frames topic:
HTTP/3 currently lacks explanation about how GOAWAY works with MAX_STREAMS (see #2629). So my suggestion pre-empts that without much thought put into the final fix. Therefore it might be wrong. Some weak arguments: 

Before sending a GOAWAY, there is no explicit limit set by the server. The stream ID limit is implicit and real but more importantly, you don't invoke the requirement `a connection SHOULD send an initial GOAWAY frame with the last Stream ID set to the current value of QUIC’s MAX_STREAM_ID and SHOULD NOT increase the MAX_STREAM_ID thereafter.`. Imagination required on how we fix this language up for MAX_STREAMS.

>From Alan's problem statement description, I imagined GOAWAY to operate more like a drain state trigger. So having separate frames would allow the draining of unidirectional traffic and bidirectional traffic independently. E.g. a client declares "I'm intending to leave soon, and I don't want to accept new things from you (pushes) but I want the ability to create new requests, so please continue to give me bidi stream credits".

On a more practical level, a frame that includes both fields when only one type wants to be drained will likely end up with a set to max_int. So we'd waste bytes to express "don't do anything". Modelling this by making fields optional adds complexity for little gain. 

Finally, we a separate GOAWAY for unidirectional streams opens the door for it to be an extension frame. However, I think this would be the wrong thing to do as it would make managing extensions very difficult.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: