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

David Benjamin <notifications@github.com> Thu, 08 August 2019 03:29 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 CFC0E120094 for <quic-issues@ietfa.amsl.com>; Wed, 7 Aug 2019 20:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U085nACjPfc1 for <quic-issues@ietfa.amsl.com>; Wed, 7 Aug 2019 20:29:22 -0700 (PDT)
Received: from out-1.smtp.github.com (out-1.smtp.github.com [192.30.252.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C2C120033 for <quic-issues@ietf.org>; Wed, 7 Aug 2019 20:29:22 -0700 (PDT)
Date: Wed, 07 Aug 2019 20:29:21 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1565234961; bh=vaRi1FpvyFFF9N2x3UsbOiimMhWnSPZYtseIjJ/ZPIw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=s5Y4C/BRkKgKUIDSHMOhfGVVwFkYJr+22Lo8DAtuxA3/wYzN+hYitZd8Lf6Wf2nZg Im1n4RELu4L6tN/7RMK7iQX7ZKQCQFRbmfkCpznQx93feX2/38MytEZEUWeBNJK2fJ FoqiA2YLNpNLwtei+OSZVnLzfHBhRFbB8Dc/qpTI=
From: David Benjamin <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYMBOJ2W7ISUCSWWH53LDEZDEVBNHHBYVUFKY@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/519348492@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2945@github.com>
References: <quicwg/base-drafts/issues/2945@github.com>
Subject: Re: [quicwg/base-drafts] When to send the SETTINGS frame (#2945)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d4b971140b4c_2ade3fa2152cd96c104129a"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: davidben
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/3ChZ24b6mmQrlq7NQE26CinvVQY>
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, 08 Aug 2019 03:29:24 -0000

It's not really optional right now. This bit here is a problem: "The server MAY omit settings from its SETTINGS frame which are unchanged from the initial value". That means, if the client doesn't remember the SETTINGS information, due to, say, packet ordering, it won't apply this SETTINGS frame delta correctly. Having both sides disagree on how to interpret a SETTINGS frame is rather poor. Moreover, this mismatch is sticky. If you get out of a sync once, you stay out of sync as you renew tickets.

To that end, I guess there's yet another option: strike that sentence. The server must encode the SETTINGS de novo, and the client can start with either the initial value or the cached value. That ambiguity is odd, but the client already starts with the initial value at 1-RTT, so I think that's less of a nuisance.

Putting SETTINGS in the transport parameters gives it an ordering: it's guaranteed to be processed before NewSessionTicket. (And HTTP requests[*], for that matter, so it's an improvement in the 1-RTT case too.)

[*] More accurately, it's guaranteed to be processed before 1-RTT HTTP requests, but 0-RTT HTTP requests get the remembered one, so you still get to rely on some form of SETTINGS.

-- 
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#issuecomment-519348492