[quicwg/base-drafts] HTTP/3 unidirectional streams arms race (#2559)

Lucas Pardue <notifications@github.com> Wed, 27 March 2019 03:17 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AF120132 for <quic-issues@ietfa.amsl.com>; Tue, 26 Mar 2019 20:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RGxZCRag8_TP for <quic-issues@ietfa.amsl.com>; Tue, 26 Mar 2019 20:17:06 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408E11200D8 for <quic-issues@ietf.org>; Tue, 26 Mar 2019 20:17:06 -0700 (PDT)
Date: Tue, 26 Mar 2019 20:17:04 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1553656624; bh=f9nPBUl3CR+vDUDQbi1eaYE8AGGSU6OV6avc14V6E2I=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=UGjzUw6dNnIp13nIHvlWItvHlCNcZqG+fsj2qYBwcUztfAphZLJzD/rb3E5OB4TPM e9y89l80UAK+ImZfUU/IB9fcrkRhxFlV9zlBQI1wQvqygKMYVfCun+EuP79gCK91Yg 0PvQuXewmO+32iFunjaR3UYc5/EoWkqYnPJ+Xxds=
From: Lucas Pardue <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe3f07624ab42ade9bb75c43f0d500944b7e2e22892cf0000000118b2ad3092a169ce196054ab@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2559@github.com>
Subject: [quicwg/base-drafts] HTTP/3 unidirectional streams arms race (#2559)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c9aeb3084657_76d73fb0a20d45c0215aa"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/pCt4PsLgNOXnTc_HoUjOcz1H204>
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: Wed, 27 Mar 2019 03:17:09 -0000

In Tokyo 2019, we discussed #2100 (Avoid creating QPACK streams when unnecessary) and came upon the conclusion:

> Discussed in Tokyo; do not require creating the streams, but creating them is not forbidden even if the setting prevents their use.

Until such a change is applied to the HTTP and QPACK specs, we rely on the guidance in section 3.2:

> Both clients and servers SHOULD send a value of three or greater for
   the QUIC transport parameter "initial_max_uni_streams".

There is an implicit assumption in this present state that assumes these three streams will be used for the "critical streams" - Control stream, QPACK Encoder Stream and QPACK Decoder stream. The outcome of the Tokyo discussion didn't seem to me to identify the impact on initial_max_uni_streams. 

HTTP/3 reserves code points for GREASING but doesn't provide much guidance on their usage. It says "MUST ignore" and CAN send reserved stream types. In contrast Transport is a little stronger and says that:

> A server SHOULD include a reserved version (see Section 15) while generating a Version Negotiation packet.

Not sending GREASE negates its powers. 

GREASE streams are not the only consumer of unidirectional credit. It seems feasible that an endpoint might optimise for some use cases and decide push on 2-out-of-three streams it was given the credit for. This depends on receiving MAX_PUSH_ID on the control stream, of course.

The control stream unfortunately has dubious language:

> Each side MUST initiate a single control stream at the beginning of
   the connection.

When is the beginning of beginning and when is the end of beginning? Mike somewhat answered this question in #2038 (Default settings in HTTP):

> You're still required to send/consume SETTINGS -- you're just allowed to use a basic version of the protocol for the (hopefully very brief) period where you haven't seen it yet. I'm dubious anyone would decide it's better to send an empty SETTINGS frame and continue using the defaults forever, certainly not to the point that extensibility withers.

Is the end the beginning once SETTINGS have been sent?

PR #2529 was an attempt at scurry along the spec change #2100 wanted. Created in response to hitting an interop issue causes by the old requirement to "MUST create one QPACK Encoder and Decoder stream" conflicting with the "SHOULD allow initial max 3". However, the issue I see with the way the specs would look like with this specification is that there is not much determinism on how an endpoint should use MAX_STREAMS and how it can the unidirectional streams it makes available will be used. For example,

* a client advertises 3 initial max uni streams, likewise a server advertises 3
* a server creates a 2 grease streams and 1 encoder stream
  * Recall the Tokyo outcome was "creating them is not forbidden even if the setting prevents their use" and by default value of SETTINGS_QPACK_MAX_TABLE_CAPACITY is 0 if you never receive a SETTING that tells you otherwise
* the client expects 3 "critical streams", so banks the difference (2) and gives unidirectional stream credit by sending a MAX_STREAMS frame of value 5
* the client opens a grease stream, a control stream, and 1 encoder stream
* the client sends MAX_PUSH_ID = 3
* the client sends a request with static compression
* the server sends 3 PUSH_PROMISES and attempts to push 3 resources.
* the server wishes to open N unidirectional extension streams
* the server sends STREAMS_BLOCKED with the value of 5
* the client sends a request with dynamic compression
* the server wishes to open a decoder and sends STREAMS_BLOCKED with the value of 5

a) What value of MAX_STREAMS is suitable for a client to send?
b) if the value is < N+2 what is a suitable rate to send STREAMS_BLOCKED?
c) will this just devolve to a cycle of one endpoint sending STREAMS_BLOCKED and the other echoing back MAX_STREAMS (value +1) until the other side shuts up?

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