[quicwg/base-drafts] When to send the SETTINGS frame (#2945)

Kazuho Oku <notifications@github.com> Thu, 01 August 2019 02:01 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94743120131 for <quic-issues@ietfa.amsl.com>; Wed, 31 Jul 2019 19:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jc66H_hOJF42 for <quic-issues@ietfa.amsl.com>; Wed, 31 Jul 2019 19:01:10 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FC0C12010C for <quic-issues@ietf.org>; Wed, 31 Jul 2019 19:01:10 -0700 (PDT)
Date: Wed, 31 Jul 2019 19:01:09 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1564624869; bh=UFhEJ3F0YP5eJeflrCt5CGem49iJ0+xEkB4CQc2kIVc=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=oAXkKwILdfCoJ8gETFZ1z+7Fh8rDOxHJl7EjkuUT8SiDlAaRWSI564XejL1Ghhg/k DYzl83XsP6CGYs4+6ck5yb+6wyPayOromrQiZzuNcMUySPueAX3Rfse1GxjqTkJN6x mMtxctm/smewAaMYAmomsf9Hskrz3fT0Bn9eO78k=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK74XEIAHXVSX4QSU7F3J55GLEVBNHHBYVUFKY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2945@github.com>
Subject: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4247e55afcc_4d583ff3f74cd96818097"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/ruGp47VHa_eQ2Mcpsg5IKFbl1HY>
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: Thu, 01 Aug 2019 02:01:13 -0000

It seems that there are disagreement among the implementors, regarding when the SETTINGS frame need to be sent.

Some argue that it needs to be sent right after the handshake, even if the SETTINGS frame would contain no parameters. Some argue that it can be delayed, until the need to send something on the control stream arises.

I think we should clarify the expected behavior.

FWIW, existing text that refers to the topic are:
[section 3.3](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.3.3):
> 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)

[section 6.2.1](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.6.2.1):
> Each side MUST initiate a single control stream at the beginning of the connection and send its SETTINGS frame as the first frame on this stream.

[section 7.2.5](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#rfc.section.7.2.5):
> SETTINGS frames always apply to a connection, never a single stream. A SETTINGS frame MUST be sent as the first frame of each control stream (see Section 6.2.1) by each peer, and MUST NOT be sent subsequently.

cc @DavidSchinazi @LPardue @rmarx 

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2945