[quicwg/base-drafts] HTTP/3 settings frames and prioritization (#2772)

"Tom D." <notifications@github.com> Wed, 05 June 2019 14:04 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 25784120099 for <quic-issues@ietfa.amsl.com>; Wed, 5 Jun 2019 07:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 2irU1WpGn7qu for <quic-issues@ietfa.amsl.com>; Wed, 5 Jun 2019 07:04:26 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.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 C5D68120048 for <quic-issues@ietf.org>; Wed, 5 Jun 2019 07:04:25 -0700 (PDT)
Date: Wed, 05 Jun 2019 07:04:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1559743464; bh=yQU0V7PXJTldpemEzwWPoV+LgTYSG13do1aUFAksWbM=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=vbAQF35e11ASO4EZ+kLmtZxMerHoQGGxWIdkAIGBP7UxWyyf9fMzu49Sn+diGEpz3 LV/Q4DYfrZUF6h5m4Zq+mAJeivpFLfw+sSt8J1ekcDUwc+yq+KJLrrI9EWPAdalh5U W4HZP1gqcV59BGaHpVnmrXoNH3c1w6ZcGPRpEC8A=
From: "Tom D." <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3HE4FNCR6SJMVOCIV3AT7GREVBNHHBV6HKDU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2772@github.com>
Subject: [quicwg/base-drafts] HTTP/3 settings frames and prioritization (#2772)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cf7cbe87cdc8_3b783f942cecd95c3277db"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tomdedecker
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/98mgXipSHE7vtXEmnZZOvlISGsc>
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, 05 Jun 2019 14:04:28 -0000

My issue is the following: The current HTTP/3 specifications say that a SETTINGS frame must be sent as the first frame of the control stream directly following QUIC connection establishment.

While connection-level options pertaining to the core QUIC protocol are set in the initial crypto handshake, HTTP/3-specific settings are conveyed in the SETTINGS frame. 
After the QUIC connection is established, a SETTINGS frame (Section 7.2.5) MUST be sent by each endpoint as the initial frame of their respective HTTP control stream (see Section 6.2.1).

Depending on how connection establishment is defined, this could result in some awkward client-sided behavior. There are two ways to interpret connection establishment as far as I can tell:
1. The moment the server has 1-RTT send-keys available (i.e., after Client Hello)
2. On receipt of the client finished TLS packet

In the first case, the server can specify its settings before the client makes its first request. In the second case however, the client can already send its first request before having received the server's settings. To handle this case, the specifications say the following:

An HTTP implementation MUST NOT send frames or requests which would be invalid based on its current understanding of the peer’s settings. 
All settings begin at an initial value, and are updated upon receipt of a SETTINGS frame. 
For servers, the initial value of each client setting is the default value.

Now say for example that a client wants to use Firefox's prioritization scheme and connection establishment is defined in the second way (receipt of client finished packet). Ideally it would use placeholders to structure the dependency tree, but as it has not yet received a settings frame, it is not allowed to do so (default placeholder count is 0). This gives the client two options from what I can tell: 
1. Wait for the settings frame to arrive (and therefore block, which isn't exactly elegant)
2. Use a fallback prioritization scheme and reprioritize requests later when the settings frame has been received and it allows the placeholders the client wants to use (which we'd also ideally like to avoid).

As neither of these options are preferred, the importance of the definition of connection establishment is highlighted even more. My request is, if a clear answer has already been thought out, to add a more verbose description of what connection establishment actually means in this situation.

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