Re: Stream State and PRIORITY Frames

Patrick McManus <pmcmanus@mozilla.com> Thu, 19 January 2017 16:26 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 EEEB712964D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Jan 2017 08:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-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 UHa6P5_p7iZT for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 19 Jan 2017 08:26:14 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F3F5129641 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 19 Jan 2017 08:26:14 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cUFV5-0006Am-2n for ietf-http-wg-dist@listhub.w3.org; Thu, 19 Jan 2017 16:23:47 +0000
Resent-Date: Thu, 19 Jan 2017 16:23:47 +0000
Resent-Message-Id: <E1cUFV5-0006Am-2n@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <pmcmanus@mozilla.com>) id 1cUFV1-00069z-8L for ietf-http-wg@listhub.w3.org; Thu, 19 Jan 2017 16:23:43 +0000
Received: from www.ducksong.com ([192.155.95.102] helo=linode64.ducksong.com) by titan.w3.org with esmtp (Exim 4.84_2) (envelope-from <pmcmanus@mozilla.com>) id 1cUFUs-0001ZK-Cu for ietf-http-wg@w3.org; Thu, 19 Jan 2017 16:23:38 +0000
Received: from mail-yb0-f169.google.com (mail-yb0-f169.google.com [209.85.213.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id CFC9D3A01B for <ietf-http-wg@w3.org>; Thu, 19 Jan 2017 11:23:12 -0500 (EST)
Received: by mail-yb0-f169.google.com with SMTP id w194so25086277ybe.0 for <ietf-http-wg@w3.org>; Thu, 19 Jan 2017 08:23:12 -0800 (PST)
X-Gm-Message-State: AIkVDXK4sKCJDpjyM9EtDT66/Jhfe9mjxY0vx4cHv2QbU9TTLc79tCbcUni/69E8NWR/2e0+J90F4zb8QJSLfw==
X-Received: by 10.237.32.70 with SMTP id 64mr7919666qta.163.1484842992581; Thu, 19 Jan 2017 08:23:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.162.65 with HTTP; Thu, 19 Jan 2017 08:23:12 -0800 (PST)
In-Reply-To: <e420eda0-57fc-43e8-a82a-0988db75ab32@treenet.co.nz>
References: <CAFn2buAYWHQSWhhoKZ2GKbqXR1A+tScjkAwZmOuQ9gV9jMp2bA@mail.gmail.com> <CAGZNdJWe0Y=M_SWmgYabKbWZwPEuJdw67Km8+UtR4oUtZuXA5A@mail.gmail.com> <2BC01E49-91A1-43A7-AFD0-5A34F2689428@lukasa.co.uk> <CAFn2buDCMwMp=rR0C_yt4-gUwyFhY6ruonz9wT-jVMu+Kir=nA@mail.gmail.com> <C51C3F51-37BE-489F-BA1D-76B101517307@lukasa.co.uk> <CAFn2buAE-EdTEG9x-wLQSy5Osmcq1Hdps9YLW_7j9CTV4_Fuyw@mail.gmail.com> <CANatvzzEV6Qd1huVxO=T2m7UwwX207RCetrXyZ1FMMGrBtzeEg@mail.gmail.com> <e420eda0-57fc-43e8-a82a-0988db75ab32@treenet.co.nz>
From: Patrick McManus <pmcmanus@mozilla.com>
Date: Thu, 19 Jan 2017 11:23:12 -0500
X-Gmail-Original-Message-ID: <CAOdDvNrNqpvme=0HTrQQx44pE8bm-zjHdf3S6HY6hNYGeF6ErQ@mail.gmail.com>
Message-ID: <CAOdDvNrNqpvme=0HTrQQx44pE8bm-zjHdf3S6HY6hNYGeF6ErQ@mail.gmail.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="94eb2c0c98c81ee2ff054674f388"
Received-SPF: softfail client-ip=192.155.95.102; envelope-from=pmcmanus@mozilla.com; helo=linode64.ducksong.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.617, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cUFUs-0001ZK-Cu 6ebb5d2ab890c4bde31a288a787d3018
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Stream State and PRIORITY Frames
Archived-At: <http://www.w3.org/mid/CAOdDvNrNqpvme=0HTrQQx44pE8bm-zjHdf3S6HY6hNYGeF6ErQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33330
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Thu, Jan 19, 2017 at 4:00 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:

> What I'd like from Firefox is an explanation of why exactly PRIORITY is
> the first thing(s) happening here at all?
>
>
sure - see below. First, I think we need to revisit the primary motivation
for dependencies at all in h2:

When any client needs to forward requests from two or more contexts it
needs to balance them according to some policy. maybe that's fairness (each
user gets 1/2) or maybe that's some kind of class of service (foreground
tab gets 90%, other ones get 10%).. you can try and weight the streams to
make that happen, but there are N streams for each 'user' and that number
varies quickly over time, which would mean constantly reprioritizing the
weights.

The problem is solved with dependencies and grouping nodes (i.e. idle
streams). Each use can get equal weight (or whatever your policy) in
aggregate no matter how many streams come and go as long as they are rooted
in the same group.

The client in this scenario might be a proxy, looking for fairness among
users, or it might be a user-agent looking for a fair policy for balancing
different tabs. It doesn't matter.


> What exactly does it mean for them to set PRIORITY on a non-existent
> stream?
>

tl;dr; streams 3,5,7,9,b only ever have PRIORITY sent on them (and I
believe this leaves them idle). Subsequent 'normal' streams (of the HEADERS
ilk) are dependent on one of these 5 streams (generally directly, but
sometimes via a layer of indirection through another HEADERS based stream.)

These low numbered streams are 'grouping nodes' in the priority graph -
they have different weights and represent different classes of service
(things like background loads in the download manager are separated from
more low-latency things like css, etc..). As your session goes on over time
the HEADERS based streams close normally, but new navigations and uses root
themselves in the graph to those same low numbered grouping nodes - which
are meant to be persistent. They need not have full stream state (they are
after all still idle) - they are just a part of the dependency graph.. any
kind of LRU based eviction algorithm should easily keep them around in
practice.

I'm sure it will evolve over time.

It might be helpful if we had a mechanism where we could signal if one peer
made a PRIORITY assertion with a dependency that couldn't be resolved on
the other end because it evicted the relevant information.. that would let
the original peer reprioritize the stream.