Re: Experimental data on priorities

Ian Swett <> Wed, 17 July 2019 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3234C12024A for <>; Wed, 17 Jul 2019 16:54:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.251
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m8Jka0OpbtHP for <>; Wed, 17 Jul 2019 16:54:51 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id BD617120230 for <>; Wed, 17 Jul 2019 16:54:51 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hntiP-00082M-U2 for; Wed, 17 Jul 2019 23:52:05 +0000
Resent-Date: Wed, 17 Jul 2019 23:52:05 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4f]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hntiN-00081d-NM for; Wed, 17 Jul 2019 23:52:03 +0000
Received: from ([2607:f8b0:4864:20::e31]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hntiM-0002lf-1e for; Wed, 17 Jul 2019 23:52:03 +0000
Received: by with SMTP id j26so17823198vsn.10 for <>; Wed, 17 Jul 2019 16:51:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Wed, 17 Jul 2019 19:51:28 -0400
Message-ID: <>
To: Patrick Meenan <>
Cc: IETF QUIC WG <>, HTTP Working Group <>, Lucas Pardue <>
Content-Type: multipart/alternative; boundary="000000000000b49faf058de92cb3"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e31;;
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: 1hntiM-0002lf-1e 41d3eab3b8a5cf2492232624a5c98073
Subject: Re: Experimental data on priorities
Archived-At: <>
X-Mailing-List: <> archive/latest/36808
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 and 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 <> 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 <> 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