Experimental data on priorities

Ian Swett <ianswett@google.com> Tue, 16 July 2019 02:28 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 15911120025 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Jul 2019 19:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.252
X-Spam-Level:
X-Spam-Status: No, score=-10.252 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, 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 myUwmZCeec6B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 15 Jul 2019 19:28:18 -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 034241200B2 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 15 Jul 2019 19:28:17 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hnDA4-0001t2-Gp for ietf-http-wg-dist@listhub.w3.org; Tue, 16 Jul 2019 02:25:48 +0000
Resent-Date: Tue, 16 Jul 2019 02:25:48 +0000
Resent-Message-Id: <E1hnDA4-0001t2-Gp@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ianswett@google.com>) id 1hnDA2-0001sO-Hs for ietf-http-wg@listhub.w3.org; Tue, 16 Jul 2019 02:25:46 +0000
Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ianswett@google.com>) id 1hnDA0-000697-KX for ietf-http-wg@w3.org; Tue, 16 Jul 2019 02:25:46 +0000
Received: by mail-vs1-xe34.google.com with SMTP id u124so12845117vsu.2 for <ietf-http-wg@w3.org>; Mon, 15 Jul 2019 19:25:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=6YqZsyKFXBKlvjzhBky+xfSlXN+OyMrtwQ6d6kjzdH4=; b=uE6QseO7lOpwF5oP07KHpEB3LqTbR7tu55aecMgBbvscKpcby5LkvMVjh4GOeSFxMT WVanQ4JTAS9z5QPsz+Gf48wnaaC/GjFxtAvB/tCUhSfQf9JdxQ6ll1BPhfz4mrxdlGxP p05dOc0Sa0bM1gEyVDqLviCkj2Cb5o/UShFlJum9xD3yEPSPsVCKm+gUDgOgrt/eFLUE z4A83kLPf2mKjqfQ6Kho8uDguL2nUNwQjnIif9C9VW+igzgrWh7+yMtdvYRBdWQYxbn2 8UpfIhYabERGtBxk5U/qwXpA3MGMRasXeL5piawg7Y+Sez1STMVDOx/Ogzw5Fd2rXRe6 wUiA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6YqZsyKFXBKlvjzhBky+xfSlXN+OyMrtwQ6d6kjzdH4=; b=oDBkYgvgi0DKcSY8cdR5gS2F3HJy2wRo4ED9lrJnnp8gqaa8a8uiXCgYJJhqDTBx6g iVTGMp9DZe6/wSSvr29Euzvpq/c1hi0rW1ajdt3tD75V1WIMq/UXxPusKR1p6hcVHgDX VDFYi0uUgztprwGp1ZV02lCrDMU6ErFzwCQ1XhHIbcrK8vE1ZTG2AtSZdvIJAhrcHG+d MQtfQsN9Oaz2Fv8eR9ZCuLIexNRhiFLbUWxxgytNFS96TGY5JLdJdiXtrQQtczBLIX59 qhjGCvWzTuuBQCkdxswcTqCXWIupv74KCSNM76Mr/xbKMcxLw1j6U33l+0f4sythiKkn nhJA==
X-Gm-Message-State: APjAAAUmEE4kD5nOEU0BxDt3XT7taDcsMBxkVszo0ucKU0uNF5pPWuRk qZ1QTK1Gnooh3BwGKFdZmpVTynpuuG17raBE3MpfZA==
X-Google-Smtp-Source: APXvYqz+HX+4ici/wxoMXloPiRnkC7xdLQP/7NPmaeeakYhd9ila1Bmxe/z22Kl/8QS39inZgQxRsKztysQH1+5kR9k=
X-Received: by 2002:a67:eb93:: with SMTP id e19mr18633770vso.208.1563243923280; Mon, 15 Jul 2019 19:25:23 -0700 (PDT)
MIME-Version: 1.0
From: Ian Swett <ianswett@google.com>
Date: Mon, 15 Jul 2019 22:25:12 -0400
Message-ID: <CAKcm_gMZoFNhB0BoKtCZdL5QuUaGmsEcTLbiz2ZQNDV4Zym_bg@mail.gmail.com>
To: IETF QUIC WG <quic@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="000000000000befae1058dc316b8"
Received-SPF: pass client-ip=2607:f8b0:4864:20::e34; envelope-from=ianswett@google.com; helo=mail-vs1-xe34.google.com
X-W3C-Hub-Spam-Status: No, score=-19.6
X-W3C-Hub-Spam-Report: 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: titan.w3.org 1hnDA0-000697-KX ab2301d35074b0abbb8871adc33973f8
X-Original-To: ietf-http-wg@w3.org
Subject: Experimental data on priorities
Archived-At: <https://www.w3.org/mid/CAKcm_gMZoFNhB0BoKtCZdL5QuUaGmsEcTLbiz2ZQNDV4Zym_bg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36806
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>

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