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

Mike Bishop <> Wed, 23 October 2019 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0BB96120D3D for <>; Wed, 23 Oct 2019 11:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Status: No, score=-8 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_HELO_NONE=0.001, 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 fbaWQScWqCri for <>; Wed, 23 Oct 2019 11:41:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45F3D120D20 for <>; Wed, 23 Oct 2019 11:41:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA60A261650 for <>; Wed, 23 Oct 2019 11:41:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1571856092; bh=hWvAdfZbkFD4sDOqHt+Wb1T+5jsMu1879Poj8MSlTYs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YYI7iQ6klXvejVeqwSUNMrZSGmGCZS4fY1d/dfQJB0HwF/KSRhbYUGFm1NAuzLb3O yn6ydp6gzKjxDk4PUUgwYeRuZ/XIHnO6s7SM11Wa8GX7o1pORwwl+pnJasAaE0B7e9 5sxiPPZew8+KIEw8vsqPVGyw7dV8qLp9gMG1s+c0=
Date: Wed, 23 Oct 2019 11:41:32 -0700
From: Mike Bishop <>
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_5db09edc759d9_455a3f96862cd95c131580"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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: Wed, 23 Oct 2019 18:41:35 -0000

#3129 makes a subtle but major change to the semantics, and I think we need to carefully consider whether that's something we want.  We were conflating these two models during interim discussion, and I don't think we're clear on our direction yet.

Instead of "Clients MUST NOT send new requests on the connection after receiving GOAWAY", we now have "Endpoints MUST NOT initiate new requests or pushes on the connection **with an identifier greater than or equal to the smallest identifier received in a GOAWAY frame.**"  In other words, GOAWAY(`max_varint`) has changed from meaning "I'll service your in-flight requests, but don't make any new ones" to a no-op, since the client couldn't have initiated such a request anyway.

I understand that this might be a desirable pattern in the server-to-client direction, where certain use patterns consider the set of pushes part of the fulfillment of the client's request, and the client actively wants the server to continue initiating pushes until the request is complete.  This doesn't seem a wise semantic to bring to the client-to-server direction.

In HTTP/2, the recipient of the GOAWAY was prohibited from initiating any more activity (requests or pushes) regardless of the value in the frame.  My first preference is to preserve that, and actually have the same semantics as HTTP/2.

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