Re: Experimental data on priorities

Patrick Meenan <> Tue, 16 July 2019 13:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57CDE120411 for <>; Tue, 16 Jul 2019 06:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.751
X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] 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 IgGHklInwzSH for <>; Tue, 16 Jul 2019 06:04:13 -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 9B325120408 for <>; Tue, 16 Jul 2019 06:04:13 -0700 (PDT)
Received: from lists by with local (Exim 4.89) (envelope-from <>) id 1hnN5A-0006GI-8L for; Tue, 16 Jul 2019 13:01:24 +0000
Resent-Date: Tue, 16 Jul 2019 13:01:24 +0000
Resent-Message-Id: <>
Received: from ([2603:400a:ffff:804:801e:34:0:4c]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1hnN57-0006FS-PB for; Tue, 16 Jul 2019 13:01:21 +0000
Received: from ([2607:f8b0:4864:20::d33]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1hnN56-000302-4D for; Tue, 16 Jul 2019 13:01:21 +0000
Received: by with SMTP id i10so39654414iol.13 for <>; Tue, 16 Jul 2019 06:00:59 -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=ptX+PAAo9E3ByFsODD5gcNd5YlvK9gch1NLw7vtate8=; b=hZJq5UaPo8fSX0dXvXuMvnZXKfM7e2jPeBB2boSNzDDQFxfYsw6kY1wrTyONnhW4a3 C9eolG5n+ZbedUzJ//5EGtWaYoCRX1HgHdN8H+/Hj8ADPzdA8EZz+VQBjctoevaE4wJ5 wXfqmkGgAh2DujeViOlPoFP0gLzFhYcq5c3YLFqI/jdZiAiqcVO9wrz7FjbnlXC/omgO o84ZZgdpS3kYvk+ECgaexkNABEBiC3pd/uej5WdLShKKjXzAvEvxVcDZSAIZBN1SkxRK zWiC6DiIy7tiB4yWhZ2SQH9Qr1jnDHaMFIdwWtV9aR5PIYTDb4uvii2EC1Kmdi+U/uO5 3Vfg==
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=ptX+PAAo9E3ByFsODD5gcNd5YlvK9gch1NLw7vtate8=; b=h8biZtesFLAW/NS+DvMjlkZFGL8y6r0iCEJxJitfXj6PnF7MUe+75H3w5b8NC2v8od VO2JBp0pAWOdPXaXlBher9ZEu8C9I7X7WYDEGnMxQ7zPUTy95nv1rjuVqAe/lsu3f+Ys lrNOiwbYVUaBuRZnn4+UetSv5S/ncTct6ra0HEqeHq9EspWSwXvQJfmW0SuQFM1o79cJ KYjkbI43xkDT10ysw600mCNX44ke08lL4AKh/8bwi5ZtNNjrEeiEqPrvApOsnjpwQW/W Mc8b3dazsnaMj018Av68ZK2xBpgvsZ4HGI56pn1uU6i2H853j4vY6YO5pw3xX+/ZU/3G zMmw==
X-Gm-Message-State: APjAAAUfyZE3oXDivHfWvTFf6Wn578uZdwjXmie5v6A8CE7Jz0rJy/O+ mYukBkzI9Wqj1E8nLjFIcutp3+qv0TsBe1GOsS0dSP8I
X-Google-Smtp-Source: APXvYqwJ5i/nkh8sfw601hsdV/qBEn8nli4dc5Y41kA89wICPxspjsQ+TC1RmtPxTORaHGoTQSZwvFUO1h+MleCGkXQ=
X-Received: by 2002:a05:6602:220a:: with SMTP id n10mr30999048ion.205.1563282058754; Tue, 16 Jul 2019 06:00:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Patrick Meenan <>
Date: Tue, 16 Jul 2019 09:00:47 -0400
Message-ID: <>
To: Ian Swett <>
Cc: IETF QUIC WG <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="000000000000cbc042058dcbf767"
Received-SPF: pass client-ip=2607:f8b0:4864:20::d33;;
X-W3C-Hub-Spam-Status: No, score=-2.8
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1hnN56-000302-4D 268465523ec00008093c0369389441f5
Subject: Re: Experimental data on priorities
Archived-At: <>
X-Mailing-List: <> archive/latest/36807
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

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.

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.

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