Re: [quicwg/base-drafts] Default settings in HTTP (#2038)

Lucas Pardue <> Mon, 26 November 2018 19:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E474130DE0 for <>; Mon, 26 Nov 2018 11:49:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.46
X-Spam-Status: No, score=-4.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3zDVAjFMF3nH for <>; Mon, 26 Nov 2018 11:49:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AEB112D84C for <>; Mon, 26 Nov 2018 11:49:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=vzajspmwWwwMJi8bPwA/9CG6M2k=; b=Hb/b0BbBabYg+WA9 BUvT8IkjjfMLdYSpPIXh8wOfgffzMZJfLKwec+ukd2fI3x3dUFwwB29vUdCMr6C9 KEgn269XLTTp/GBf67fmYyjiT6Ti6Vi+ECyGQDWBzpzJRqvQln3pgjg7h0+fkCaV LwrENBTvOM9QVa9FDgoMwFWHAYs=
Received: by with SMTP id filter0476p1iad2-24163-5BFC4E61-1D 2018-11-26 19:49:53.498178681 +0000 UTC m=+934444.806006315
Received: from (unknown []) by (SG) with ESMTP id KOB_LearRzSH7463cb4-5A for <>; Mon, 26 Nov 2018 19:49:53.701 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id A8876A802A6 for <>; Mon, 26 Nov 2018 11:49:53 -0800 (PST)
Date: Mon, 26 Nov 2018 19:49:53 +0000
From: Lucas Pardue <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2038/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Default settings in HTTP (#2038)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bfc4e61a6ba9_2a863f97d62d45bc4821d"; 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-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak0U6Oz//+3FNUnVN4eqWm8T9EnC+UBGvqs/Ut 5RlMfZ3eaHSC1NHEr2f/Wz/Mzu8n9suZEfHnKU4CeHky/Sx0rvK+pL2Y6DxTSCRbrKKtSd9HonsXJ/ c89wtF8Q23DrirCfRD8BcHeJlRx8TYYCLa+jHE40fUmnSNaK2MZ/MfU5KesWTHTJqEIvvbiFASYZN+ 4=
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Nov 2018 19:49:56 -0000

That's a great write up but it's higher level than I was thinking.

If (and it's a big if) implementations decided it was more efficient to run
H3 on defaults without exchange of SETTINGS, we lose an effective
mechanism. This was part of the reason behind adding greasing. In practice,
I don't think this concern would play out but I wanted to identify it
before the change landed

On Mon, 26 Nov 2018, 19:33 Mike Bishop < wrote:

> @LPardue <>, I think the key point here is in
> the text added to the extensions section: "SETTINGS does not provide a
> mechanism to identify when the choice takes effect."
> There are really three types of extensions:
>    - *Advisory, purely-optional frames / streams:* Send speculatively; if
>    the peer doesn't understand, they'll ignore them. Once you see SETTINGS, if
>    it's not supported, you can stop sending to save bytes.
>    - *Non-optional semantic-changing frames / streams:* Send only once
>    you've seen SETTINGS, but okay to use as soon as you see SETTINGS -- you
>    know the peer will handle them on receipt. Need to be willing to handle
>    "surprise" arrival of these frames / streams before SETTINGS, unless
>    they're frames on control streams.
>    - *Breaking changes to interpretation of existing frames/streams:*
>    Here's the sticky one. There's no coordination point to know when the
>    change to existing elements takes effect, so the peer could interpret what
>    you send under the old or new scheme unless the extension itself provides a
>    way to identify this.
> I think this really only harms the last category, and the easiest solution
> seems to be jumping into the previous category for most extensions I can
> envision. For example, redefining DATA to be a reference to a
> unidirectional stream instead of carrying payload would fall in the third
> bucket and be hard. But if you instead defined a new EXTERNAL_DATA frame,
> you've moved into the second bucket.
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <>,
> or mute the thread
> <>
> .

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