Re: HTTP/2 GREASE experiment results

Willy Tarreau <w@1wt.eu> Fri, 11 September 2020 17:41 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 692FB3A167B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 11 Sep 2020 10:41:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.65
X-Spam-Level:
X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xTPaZtEX2LHt for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 11 Sep 2020 10:41:44 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (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 A12BB3A163A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 11 Sep 2020 10:41:43 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1kGn0h-0001EJ-7A for ietf-http-wg-dist@listhub.w3.org; Fri, 11 Sep 2020 17:38:55 +0000
Resent-Date: Fri, 11 Sep 2020 17:38:55 +0000
Resent-Message-Id: <E1kGn0h-0001EJ-7A@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kGn0f-0001DX-Vy for ietf-http-wg@listhub.w3.org; Fri, 11 Sep 2020 17:38:54 +0000
Received: from wtarreau.pck.nerim.net ([62.212.114.60] helo=1wt.eu) by mimas.w3.org with esmtp (Exim 4.92) (envelope-from <w@1wt.eu>) id 1kGn0e-00041n-6H for ietf-http-wg@w3.org; Fri, 11 Sep 2020 17:38:53 +0000
Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 08BHccDG008420; Fri, 11 Sep 2020 19:38:38 +0200
Date: Fri, 11 Sep 2020 19:38:38 +0200
From: Willy Tarreau <w@1wt.eu>
To: Bence Béky <bnc@chromium.org>
Cc: HTTP <ietf-http-wg@w3.org>
Message-ID: <20200911173838.GA8417@1wt.eu>
References: <CACMu3trhDxtMshfifQdwY5Y7cpsGSede965Rcy_djB9_=jeBqQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACMu3trhDxtMshfifQdwY5Y7cpsGSede965Rcy_djB9_=jeBqQ@mail.gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1kGn0e-00041n-6H 1958ea7e9273ff8ad25dbb845901c570
X-Original-To: ietf-http-wg@w3.org
Subject: Re: HTTP/2 GREASE experiment results
Archived-At: <https://www.w3.org/mid/20200911173838.GA8417@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38041
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>

Hi Bence,

On Fri, Sep 11, 2020 at 12:00:49PM -0400, Bence Béky wrote:
> Here is a summary of recent HTTP/2 GREASE experiments in Chrome.  The
> findings can inform deployment of new HTTP/2 extensions.
(...)
> Overall I would say the ecosystem is in a pretty good shape when looking
> from the client side.

Thanks for the detailed report. I think this confirms the benefits of
GREASE, first to spot implementation bugs, and second also to spot
specification inconsistencies or conflicts if any. That's definitely
something to keep in mind for future specs, and probably that the
wording or advices regarding how to take care of this may result in
even simpler error handling rules. I admit that a few years ago I was
having a few doubts about the benefits, but given the low number of
remaining issues you've identified and how precise they are, it
certainly helps improve interoperability and upgradability a lot.

Cheers,
Willy