Re: Experimental data on priorities
Ian Swett <ianswett@google.com> Wed, 17 July 2019 23:54 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 3234C12024A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2019 16:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Level:
X-Spam-Status: No, score=-10.251 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.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 m8Jka0OpbtHP for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 17 Jul 2019 16:54:51 -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 BD617120230 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 17 Jul 2019 16:54:51 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hntiP-00082M-U2 for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Jul 2019 23:52:05 +0000
Resent-Date: Wed, 17 Jul 2019 23:52:05 +0000
Resent-Message-Id: <E1hntiP-00082M-U2@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 1hntiN-00081d-NM for ietf-http-wg@listhub.w3.org; Wed, 17 Jul 2019 23:52:03 +0000
Received: from mail-vs1-xe31.google.com ([2607:f8b0:4864:20::e31]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ianswett@google.com>) id 1hntiM-0002lf-1e for ietf-http-wg@w3.org; Wed, 17 Jul 2019 23:52:03 +0000
Received: by mail-vs1-xe31.google.com with SMTP id j26so17823198vsn.10 for <ietf-http-wg@w3.org>; Wed, 17 Jul 2019 16:51:41 -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=WhvVwKSkt/Sa0zq1ry/w4QmSeB49/s26DOewBOTROV4=; b=EGQ1Z81kiU92eVEgSNaZMb890fgFsExNXVOCEbItMCMINAR/SeqA7S4ggJg96eYpkl cvqY0AffNr67n8BLRBBX1bQDyLHu2qYKLvpXzIT35ZYiRRV6/5bccM4zOFR8NxML/6lq 3QJ01MHbcJ6jIwq03UoFjpFcJeoaniBpSkp4hkxUa65KWwvY5nwrdqUxLdgug6jKEYC8 O69H0aQXf/32Zneioazv075SQ4Gj8ZpyAT9WJFOdC3RrqhGeg2MDudpPG0VMOnR22PnU VW982+sstgTndyJbJlD3EujmbHHsDQqCqbfIztpqCx9VkjJaM2/cmgCBce5O3+NdAurG KQRg==
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=WhvVwKSkt/Sa0zq1ry/w4QmSeB49/s26DOewBOTROV4=; b=AOtRarPFCz8Akska36E+tvS7X/O+mwiqlfWIKVMmQQ5GhZbMJ5uJ7bOPO0ilW2zFbM n/WRlpXneGgBogUpNwGMZvrNjlMxp4XZC5YjtVogaCq2ke+T8lZD/ZeQ+OG+2RsxPfkS W6jFwa7J5iMuzEvo4tsQZiFeOL/P9WLjJYFuk7CP93V+bBKQGCDeBkaAK3a5TGJG3SmD 2Recbrnd2b9VJhGm21JD/U1IRcpbIQLOKeI8gDCgNYAdzNJPZf8YAZqGWVpDrNiG49y7 iZ5zian1t1Tw+VjZ9wsdV6KwOvkgfK27+gpZgLtI6TiGcuUINoLg6hOpeJviOELkQU4u cBGQ==
X-Gm-Message-State: APjAAAV1ogcD/wKMW7WfaC+YjVoj2mSIZrVY4kSv1m7ApswalGfzogYO Z0UtdZVbUXRu+nVWV9OXUc0Iq9WOWcCVF3TT2xPlmg==
X-Google-Smtp-Source: APXvYqykgCNPzG0Pg9Am33LAvuUgoVs568ieriHvtbzo2pNvoZBIFHLeR3Jxv0elN1T4+rLZB2pADpgygj33oPLaEvQ=
X-Received: by 2002:a67:2d0f:: with SMTP id t15mr26503819vst.26.1563407500458; Wed, 17 Jul 2019 16:51:40 -0700 (PDT)
MIME-Version: 1.0
References: <CAKcm_gMZoFNhB0BoKtCZdL5QuUaGmsEcTLbiz2ZQNDV4Zym_bg@mail.gmail.com> <CAJV+MGzoFv+CKBPnFmXwAiDc25xd5BFc3HhmTGap5QTNEMqrnw@mail.gmail.com>
In-Reply-To: <CAJV+MGzoFv+CKBPnFmXwAiDc25xd5BFc3HhmTGap5QTNEMqrnw@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 17 Jul 2019 19:51:28 -0400
Message-ID: <CAKcm_gMe_bCZFe0BgCif-O3b5+H7g_HtcQhGaOGR=J7eeNXybw@mail.gmail.com>
To: Patrick Meenan <patmeenan@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, Lucas Pardue <lucas@cloudflare.com>
Content-Type: multipart/alternative; boundary="000000000000b49faf058de92cb3"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e31; envelope-from=ianswett@google.com; helo=mail-vs1-xe31.google.com
X-W3C-Hub-Spam-Status: No, score=-18.3
X-W3C-Hub-Spam-Report: AWL=1.333, BAYES_00=-1.9, 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 1hntiM-0002lf-1e 41d3eab3b8a5cf2492232624a5c98073
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Experimental data on priorities
Archived-At: <https://www.w3.org/mid/CAKcm_gMe_bCZFe0BgCif-O3b5+H7g_HtcQhGaOGR=J7eeNXybw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36808
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>
Mikkel, the 'why' is complicated and varied I suspect. In Google's case, I know we like to isolate services like authentication from static content from ads from large content(ie: YouTube) for a variety of reasons. I suspect we currently end up with as many as 2x more connections than we really need, and we can likely fix a few of them, but I anticipate we'll end up with >2 connections for the foreseeable future. Why TaoBoa.com and TMall.com(both Alexa top 10) were using >20 H2 connections is quite confusing to me, or why Amazon is using 15 H2 connections, so I'd be curious if anyone knows. On Tue, Jul 16, 2019 at 9:00 AM Patrick Meenan <patmeenan@gmail.com> wrote: > Lucas can speak to the current state of deployment at Cloudflare but the > scheme we deployed mirrors the current proposal well enough that the > results should apply. It's a little different because the prioritization > isn't originating from the client but it is being applied as if it was. > > Cloudflare has ample evidence that "it works" at least in place of > HTTP/2's scheme over TCP and compares well to a well-implemented HTTP/2 > client (when serving web content to browsers anyway). Where the really big > gains came into play were in overriding the client-requested prioritization > from Safari and Edge and applying something that looks more like a mix of > Chrome and Firefox (sequential critical assets, interleaved images). In > that case it worked much better than HTTP/2 but it was because of the > specific client HTTP/2 priority schemes and the bulk of the gains came from > applying better sequencing server-side (though the ability to make > server-side decisions was a huge benefit of the scheme). It also works > well enough that the new scheme is applied independent of the client so > Chrome and Firefox also don't regress. > Thanks, this makes complete sense to me. > > Given that you can represent the proposed scheme in it's entirety with the > HTTP/2 schemes, I'm not sure you'll ever see an application performance > gain if you are using the same client and applying the exact same scheme to > both modes. That said, the code complexity may prevent some features from > being implemented in the tree that could be added fairly easily to the new > scheme. The one that comes to mind for Chrome in particular is to enable > interleaving of image data instead of delivering them sequentially. With > the new scheme it's pretty much just carrying a bit through the stack to > indicate that the given fetch should be interleaved and it can be mixed in > to the serialized priorities trivially. Doing the same with the full HTTP/2 > tree would be considerably more complex. > Agreed, we're starting to write the code to compare gQUIC's use of SPDY priorities with Chrome's usage of the H2 tree with your proposal(in this case, basically a variant of SPDY priorities), and we think that should be relatively straightforward, but anything more complex would be a large amount of work. > On Mon, Jul 15, 2019 at 10:29 PM Ian Swett <ianswett@google.com> wrote: > >> When I presented slides on HTTP/3 priorities at the QUIC interim, one >> consistent point was that the HTTP/3 working group wanted some experimental >> evidence that an alternate scheme worked in practice. gQUIC has always >> used SPDY style priorities, FWIW, but we have no comparative data at >> the moment. >> >> I can imagine a few ways to evaluate a priority scheme, but I'd like to >> know whether I have the correct ones(and relative importance). >> - Application performance >> - Code size/complexity >> - Bytes on the wire >> - Computational complexity/potential for attacks >> - Reduction/change in edge cases(particularly for HTTP/3 without HoL >> blocking) >> - New capabilities (ie: easier for LBs/AFEs to contribute?) >> >> *Experimentation Options* >> The H2 stack at Google supports FIFO, LIFO and H2 priorities. However, >> it’s not currently using LOWAT and previous experiments have yielded no >> measurable change in performance, so H2 does not seem like a good >> experiment platform. >> >> For gQUIC, we already have an implementation of H2 priorities that we’re >> not using. We can wire up an experiment to start using them and compare to >> SPDY style priorities, but given Chrome's internal priority scheme with 5 >> levels and translation to a linked list in H2 priorities, I believe that >> would only provide information on code size/complexity and bytes on the >> wire. Application performance would only change if one of the two schemes >> had an implementation bug. >> >> Expanding Chrome’s usage of priorities is possible, but it’s a longer >> term project and I don't know whether they'll change. >> >> *Other data* >> Most thinking about priorities is based on the idea that a page is loaded >> over a single connection, but in fact, that’s extraordinarily rare as I >> presented at the interim(except Wikipedia). Would it be useful to have >> more data on this from the client and/or server perspective? >> >> We'd be happy to work with someone else on gathering data as well, >> assuming the WG would find the data we're gathering more valuable than what >> Chrome/Google can provide alone. >> >> Thanks, Ian >> >
- Experimental data on priorities Ian Swett
- Re: Experimental data on priorities Patrick Meenan
- Re: Experimental data on priorities Ian Swett