[quicwg/base-drafts] Server's SETTINGS can be omitted in 0-RTT (#1809)

Mike Bishop <notifications@github.com> Thu, 27 September 2018 23:49 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 76732130DD8 for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 16:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 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, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yoneSarssMG8 for <quic-issues@ietfa.amsl.com>; Thu, 27 Sep 2018 16:49:57 -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 C1749128A6E for <quic-issues@ietf.org>; Thu, 27 Sep 2018 16:49:57 -0700 (PDT)
Date: Thu, 27 Sep 2018 16:49:57 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538092197; bh=X6QJJDz7f3RSig0tJ6SkFFRrPb9pUBTs7dxx1Si7UWY=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=mvmfEXH7cXCdBlh1d1lxPSwzu+ULIefxfyUVTTtd0fAfgy7+KspL7uvLU3gbDluhb j40wNxXCVlXMUGeUOLVuAWDC4lv/ke7lyv9Ma0GeVtXSxfXNm7GTQQ5FHLMIEUsINK DeLf2NI1H4YFLYPVOgAvej9mItKL+VJegyqnHDwo=
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab594f1399a59a420acf15a8866792cde451682a5292cf0000000117c52ea592a169ce15bcc36c@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1809@github.com>
Subject: [quicwg/base-drafts] Server's SETTINGS can be omitted in 0-RTT (#1809)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bad6ca5b7af_5d2b3fe99f8d45b4215888"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MikeBishop
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/IT0Z1k8sBksrbup7UojIEij5nbs>
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, 27 Sep 2018 23:50:00 -0000

#1808 adds a requirement to error out if the first frame on the control stream is not SETTINGS.  There's an existing error for duplicate control streams.  But what if the control stream never opens at all?

The current state of SETTINGS is that:
- In 1-RTT: Clients MUST wait until they see the server's SETTINGS frame before sending requests; the server MUST see the client's SETTINGS before sending any responses.  If either side fails to open the control stream and send SETTINGS, the connection stalls.
- In 0-RTT:  Servers MUST wait until they see the client's SETTINGS frame before sending responses; this is no different.  Clients, however, assume previous settings and update them *when* the server's SETTINGS frame is eventually seen.

It is a violation for the server to send responses without having sent the SETTINGS frame.  However, there is no requirement that clients validate this behavior because of reordering.  This means that a spec-conformant client would interop just fine with a server that never sends SETTINGS on 0-RTT connections.

Should we introduce a wait-for-SETTINGS requirement later in the connection (for example, before sending new requests in 1-RTT), or just hope that it's easier for servers to do the same compliant thing for both 0-RTT and 1-RTT connections?

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