Re: HTTP/2 GREASE, Results, and Implications

Ian Swett <ianswett@google.com> Thu, 31 October 2019 16:10 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E327C120820 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 09:10:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.25
X-Spam-Level:
X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7pYZBEaf2lYX for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 31 Oct 2019 09:10:24 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1AF1200C5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 31 Oct 2019 09:10:24 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1iQCzn-0007Du-8s for ietf-http-wg-dist@listhub.w3.org; Thu, 31 Oct 2019 16:08:23 +0000
Resent-Date: Thu, 31 Oct 2019 16:08:23 +0000
Resent-Message-Id: <E1iQCzn-0007Du-8s@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ianswett@google.com>) id 1iQCzl-00078J-PX for ietf-http-wg@listhub.w3.org; Thu, 31 Oct 2019 16:08:21 +0000
Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]) by mimas.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <ianswett@google.com>) id 1iQCzj-0003rG-Oe for ietf-http-wg@w3.org; Thu, 31 Oct 2019 16:08:21 +0000
Received: by mail-vs1-xe32.google.com with SMTP id i22so4431249vsl.8 for <ietf-http-wg@w3.org>; Thu, 31 Oct 2019 09:08:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3SAXQpQQEisBwHqv1s1F2RCHvsNclcbqPk0TZ4Bm8oU=; b=rd2rWZF4msK3dcec3dOKvt7feSw39+XXMnpZbq19lYErZwF+azY14XtY10Lrijr7bp DG/pns2m/jytF3om6p7pzV1+x9rwrpkwywiAyBsrvgXkjwGD44nTmpezJia5DzENBkD1 0YCsgCL/h6RxYAEhxwPBKxqE/PJlXmmXXgWtwvhC9v1WviCgk9PIxfhGLVSWnb1AIhEc 8ETPPPAs7RbrvFFnG9rfo5PeofVzDODoOwlifVuTYvDUP5fXiMkVpYCBGcnvyoWhvTz5 EIHk4012aqWq/B6YLpdVKyRl6kZQwwNySny3s5McvfS+bGpIu6aIU2uhhvKMkOP/LYSL KuVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3SAXQpQQEisBwHqv1s1F2RCHvsNclcbqPk0TZ4Bm8oU=; b=mY9i9N+PLWwrkuBju0hgcvJjuU5Zz8BUkmFczZz8cHaWPw/yxc0+01EmA7nfsBstkf EyBUchGDADCsNI6kAu6a8g37yaMkmBGUwjlusOLbrntM1FHgaASuGNaGrXTBubGee+Uo kQMPigAy+8fyBsUQJ1U8Gw7gWcXbA/f/ktMusyslblqLivfOzu9vnQhwRF1U2Qv5clez 1XezpjxdrQ3LvKgiv9b5p9RdQ/dbbnKe9wv7j8IBNREYDFJXk7E3zBp/QA621pFs5G+7 Q19E70YdHvAYos/CDzEWIQKr8DfopkQM1uHrBPFZ2j3Ove//mJuWpjY2ixo9u2maagG5 pCKA==
X-Gm-Message-State: APjAAAXKj/LsOR+SjkhCZOHUcafP4qwfNySqiy1NvG0zyJbBw0quQ1p4 Gyky40k4qk69cv1mBX8Rsp3z1RmhZmPJA9av53NEDA==
X-Google-Smtp-Source: APXvYqyAbmeRXprmQB6oWZO611wU7SxSUVqHKDQuyI9o2N9dt+xXKfiT8KJgmNxU+grEzOKI8+lpx+lAeJNg7uC5RIs=
X-Received: by 2002:a67:3054:: with SMTP id w81mr3290203vsw.208.1572538097916; Thu, 31 Oct 2019 09:08:17 -0700 (PDT)
MIME-Version: 1.0
References: <BN6PR2201MB1700D10A34C72213C78E09A6DA630@BN6PR2201MB1700.namprd22.prod.outlook.com> <CALGR9oZUHDbsvWUJ=r0TBDaKOwchWux5gEF+EH0cpb6hqcs-xA@mail.gmail.com> <BN6PR2201MB1700996BA38EC2FED189E876DA630@BN6PR2201MB1700.namprd22.prod.outlook.com>
In-Reply-To: <BN6PR2201MB1700996BA38EC2FED189E876DA630@BN6PR2201MB1700.namprd22.prod.outlook.com>
From: Ian Swett <ianswett@google.com>
Date: Thu, 31 Oct 2019 12:08:06 -0400
Message-ID: <CAKcm_gMzPZrw14DUy5LMuWE-5dfvou22mghenS6U7my=Ti7cmg@mail.gmail.com>
To: Mike Bishop <mbishop@evequefou.be>
Cc: Lucas Pardue <lucaspardue.24.7@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000b9521c0596370ef2"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=ianswett@google.com; helo=mail-vs1-xe32.google.com
X-W3C-Hub-Spam-Status: No, score=-19.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1iQCzj-0003rG-Oe 54c44585e63ca159935604d330ed16f6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE, Results, and Implications
Archived-At: <https://www.w3.org/mid/CAKcm_gMzPZrw14DUy5LMuWE-5dfvou22mghenS6U7my=Ti7cmg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/37087
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

If only some servers accepted SETTINGS, that would further constrain the
negotiation process to only allowing the server to send the SETTING after
receiving the client's.  It'd be good to know if that's necessary, but
hopefully it's not.

On Thu, Oct 31, 2019 at 11:59 AM Mike Bishop <mbishop@evequefou.be>; wrote:

> Bence’s experiment didn’t cover anything server-sent, that I’m aware of.
> Of course, if Cloudflare would like to do a corresponding experiment…?  😉
>
>
>
> *From:* Lucas Pardue <lucaspardue.24.7@gmail.com>;
> *Sent:* Thursday, October 31, 2019 11:46 AM
> *To:* Mike Bishop <mbishop@evequefou.be>;
> *Cc:* HTTP Working Group <ietf-http-wg@w3.org>;
> *Subject:* Re: HTTP/2 GREASE, Results, and Implications
>
>
>
>
>
> On Thu, Oct 31, 2019 at 3:14 PM Mike Bishop <mbishop@evequefou.be>; wrote:
>
> Way back when, I presented a draft (
> https://tools.ietf.org/html/draft-bishop-httpbis-grease-00) proposing
> that we adopt as an HTTP/2 extension the same behaviors that HTTP/3 is
> specifying, permitting the greasing of settings and frame types.  The
> outcome of that discussion was that, prior to considering adoption, we’d
> want to understand the real-world impact of deploying such a behavior.
> Bence generously volunteered to add such an experiment to Chrome, which he
> has done.
>
>
>
> The results are discussed at https://crbug.com/1019410.  TL;DR:  Settings
> are fine, but too many servers blow up on unknown frame types for this to
> be viable in major client deployments.  They don’t even tell you what they
> don’t like – they just PROTOCOL_ERROR on you.
>
>
>
>
>
> Thanks for the experimentation and sharing the results Mike and Bence.
>
>
>
> Is the sense that this is symmetrically broken? Do we have data about how
> server-sent GREASE frames might break clients? (and if not would that move
> the needle at all).
>
>
>
> Frankly, this makes me quite sad.  It means that our primary extension
> mechanism for HTTP/2 has already rusted shut, and it’s now inadvisable to
> define new optional-to-understand frame types and send them without prior
> negotiation.
>
>
>
> Now that we have this data, are we interested in pursuing the draft with
> settings only, or perhaps reserving frame types but recommending caution in
> their use?
>
>
>
> This indeed has some practical implications to active work in the group. I
> can see how there might be some merit in capturing this situation, along
> with some guidance, in a draft that can be reference by people making
> HTTP/2 extensions.
>
>
>
> Based on my experience of HTTP/3 interop to date, we are doing pretty well
> with GREASE perhaps it is time to capture this in the matrix. I'd also like
> to highlight that today the Cloudflare edge exercises all HTTP/3 grease
> mechanisms* for all connections.
>
>
>
> * unidirectional stream type GREASE is sent when sufficient stream credit
> is provided by the client e.g. more than 3
>
>
>