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.
- Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Benedikt Christoph Wolters
- Re: Stream State and PRIORITY Frames Tatsuhiro Tsujikawa
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Matthew Kerwin
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Martin Thomson
- Re: Stream State and PRIORITY Frames Daurnimator
- Re: Stream State and PRIORITY Frames Tom Bergan
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Kazuho Oku
- Re: Stream State and PRIORITY Frames Amos Jeffries
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Patrick McManus
- Re: Stream State and PRIORITY Frames Cory Benfield
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames laike9m
- Re: Stream State and PRIORITY Frames Scott Mitchell
- Re: Stream State and PRIORITY Frames Tom Bergan
- Re: Stream State and PRIORITY Frames Scott Mitchell