Re: [quicwg/base-drafts] Greasing for Unidirectional Stream Types (#1490)

Kazuho Oku <> Thu, 28 June 2018 00:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D738D130E46 for <>; Wed, 27 Jun 2018 17:13:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Status: No, score=-8.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 7PrKT0sLC6Be for <>; Wed, 27 Jun 2018 17:13:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 16DB1130E45 for <>; Wed, 27 Jun 2018 17:13:56 -0700 (PDT)
Date: Wed, 27 Jun 2018 17:13:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1530144835; bh=Gv98E59RWRDblSFcoknwt3kRFMQrZF4Pk5MMTaL2gUg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ftxyMoYPINS6Yp1V9tS1wB4Ed+xW6VjZjF4GCgkI0vJcZUg0r+UwRSM62fptw3HlD YF2OmFgNQ2+WgkSuxIDozzvSdFjk1CA3vxg7XY0TE7j1O9CkY0lAD8UP759yebsGSS mfefT8e7Dn32CPCbXsgnaDiWb5gHz7fwlAH+/Kzs=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1490/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Greasing for Unidirectional Stream Types (#1490)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b3428436fc7c_11643ffde613af7812226f"; 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
Archived-At: <>
X-Mailman-Version: 2.1.26
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, 28 Jun 2018 00:13:58 -0000

> So taking Martin's point in mind, what about something like:
> _Implementations SHOULD NOT send stream types that the peer is not already known to support. Recipients of unknown stream types MUST send a STOP_SENDING frame with an error code of HTTP_UNKNOWN_STREAM_TYPE. Greased stream types are always classed as unknown and unsupported._

Sounds good to me. Though I might prefer using "MAY" instead of "MUST" for if STOP_SENDING should be sent. For example, if the entire flow of the unidirectional stream (i.e. from the beginning of the stream to EOS) fits in a single packet, I do not think that there is a strong reason to require the peer to send STOP_SENDING.

> It would help to provide some guidance for HTTP/QUIC extension authors to make it clear that a mechanism (e.g. SETTINGS) for negotiating extension stream types is required,

I am not sure if such requirement is necessary. In fact, I would argue that it would be beneficial allow extended stream types to be sent without negotiation.

For example, a server might send additional certificates before receiving the client's SETTINGS frame (i.e. by using in it's 0.5 RTT window, which would be idle time). Or, a client might send a cache digest before observing the server's SETTINGS frame.

To generalize the concept, I would argue that both frames and streams defined as extensions should be allowed to be sent without negotiation. The only differences are that streams can be reset by peer (by using STOP_SENDING), and that they would not suffer from HoLB (therefore it is sensible to use unidirectional streams with extended types for sending information that would have been exchanged using stream 0 of HTTP/2).

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