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

Martin Thomson <> Wed, 24 April 2019 03:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BC571203C3 for <>; Tue, 23 Apr 2019 20:01:40 -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 Wr_BkUjdQ3jx for <>; Tue, 23 Apr 2019 20:01:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B324D120319 for <>; Tue, 23 Apr 2019 20:01:37 -0700 (PDT)
Date: Tue, 23 Apr 2019 20:01:36 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1556074896; bh=2CXBeYnRr+A8bP6sHgugwWPFxtMBggYah8/ekyOA1J0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ueKyVpiKqutsQGVE+Fmytxcqe6Rr4ABYCk/6+y4vy8vnvOS4ppHei2/+XFpovpWMn zcySL02YBK0FAOMklo5R+lU0ciI9yWP5cb58QdUYvrIqXLzEhFBAxkKIre38DDfXrX RtPtO0bdFupM/OLf4iJDycEkkrBeUoMR/Imp+JV0=
From: Martin Thomson <>
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_5cbfd1909b69b_202c3f80824cd96011945c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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, 24 Apr 2019 03:01:40 -0000

I don't think that we need to make special accommodations for possible future extensions, where the requirements for graceful shutdown are unpredictable.

> I have a hard time thinking of an application where graceful shutdown requires continued creation of one of the stream types, but they may exist.

Strange.  There's an example in h3.  In order to answer a request, a server might create multiple push streams after the point that shutdown is initiated.

The model for GOAWAY in h3 is based on the realization that the primary purpose of HTTP is to provide answers to requests.  Stop the requests and you eventually run out of work.  For the client, no signaling is required.  For the server, it just has to have a way to block incoming requests.  To Ian's point about identifying requests, I believe that it does (if the text doesn't support that, that's just a bug).

Extensions can change anything.  But we can't really say what the graceful shutdown model would be without understanding the extension.  Assuming that once shutdown is initiated there will no longer be any need for new streams is not safe.

I can easily think of cases where new streams are needed to fulfill existing commitments.  Any protocol that treats streams as messages with an 1:N or N:M relationship between the message that initiates a transaction and the messages required to complete that transaction is open to this.

Take a SQL or similar exchange where a transaction is opened, some queries and updates performed, and the transaction is committed or rolled back.  A graceful shutdown might trigger rollback or it needs to allow for existing transactions to complete.  If you want to allow transactions to complete, then you might have multiple streams created after the shutdown order is issued.

And the SQL case is still simple, because it is still fundamentally transactional.  If the protocol is truly bidirectional, with either peer initiating activity that might take time, then you need a more sophisticated shutdown process.  The quanta used to measure what is accepted or rejected during shutdown might not be a discrete linear sequence as it is for simple transactional protocols; it could be multi-dimensional.  Indeed, the reason for this issue is the possibility that h3 with extensions could end up being multi-dimensional.  The stuff people are doing with bidirectional transport use could end up like that, especially where it is intended to be multiplexed with h3.

Expecting things to line up around streams is probably reasonable, but when streams are used for multiple purposes, things get messy.  You need to be identifying the unit.  We get to use streams for GOAWAY because client-initiated bidirectional streams are exclusively used for requests, but we use stream identifiers only as means of identifying requests there (again, if the text implies otherwise, we need to fix that).

So my view is that GOAWAY is good enough for shutdown of requests.  But that is all we can realistically provide for at this layer.  If an extension needs to be shutdown gracefully, then the extension that adds that thing will need to provide signaling in support of that shutdown.  Practically, that means multiple frames involved in shutdown, but that's not terrible, just wait for all shutdown-y things to complete shutdown before tearing down the connection.

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