RE: Design Issue: PUSH_PROMISE and Stream Priority

RUELLAN Herve <Herve.Ruellan@crf.canon.fr> Fri, 26 April 2013 09:34 UTC

Return-Path: <ietf-http-wg-request@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 E13A021F978E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 02:34:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.196
X-Spam-Level:
X-Spam-Status: No, score=-8.196 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-7GpWAZlAF8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 02:34:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 32E4921F978C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Apr 2013 02:34:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVf1b-0003p3-LR for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 09:33:03 +0000
Resent-Date: Fri, 26 Apr 2013 09:33:03 +0000
Resent-Message-Id: <E1UVf1b-0003p3-LR@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UVf1U-0003oO-Ab for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 09:32:56 +0000
Received: from inari-msr.crf.canon.fr ([194.2.158.67]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <Herve.Ruellan@crf.canon.fr>) id 1UVf1S-0001vz-Cz for ietf-http-wg@w3.org; Fri, 26 Apr 2013 09:32:56 +0000
Received: from mir-msr.corp.crf.canon.fr (mir-msr.corp.crf.canon.fr [172.19.77.98]) by inari-msr.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r3Q9WQAa002300; Fri, 26 Apr 2013 11:32:26 +0200
Received: from ADELE.crf.canon.fr (adele.fesl2.crf.canon.fr [172.19.70.17]) by mir-msr.corp.crf.canon.fr (8.13.8/8.13.8) with ESMTP id r3Q9WQpl024062; Fri, 26 Apr 2013 11:32:26 +0200
Received: from ADELE.crf.canon.fr ([::1]) by ADELE.crf.canon.fr ([::1]) with mapi id 14.02.0342.003; Fri, 26 Apr 2013 11:32:26 +0200
From: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>
To: =?gb2312?B?V2lsbGlhbSBDaGFuICizwtbHsv0p?= <willchan@chromium.org>, "Roberto Peon" <grmocg@gmail.com>
CC: Martin Thomson <martin.thomson@gmail.com>, James Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Thread-Topic: Design Issue: PUSH_PROMISE and Stream Priority
Thread-Index: AQHOQd+MJ5DQqSJZlUWaC8K1Nyj5UpjneY2AgAAuw4CAADBbgIAAYvPQ
Date: Fri, 26 Apr 2013 09:32:24 +0000
Message-ID: <6C71876BDCCD01488E70A2399529D5E516416A6B@ADELE.crf.canon.fr>
References: <CABP7Rbf_hZ036vUs4LNTrGQ91kft2_97aV-9Gi2KVJnUJphbNA@mail.gmail.com> <CABkgnnUBEvDtNQM8G5vyfyqRz4tQ8su9+14gMTdaXhzY2cq+Kg@mail.gmail.com> <CAP+FsNdxCcs+J3nhFE6nusAsZLwSG=WMEhHZK0FZjgQQVveHAw@mail.gmail.com> <CAA4WUYgvC_EbEkhMFsH_KuK3U5O=csGAFKmdw1XVn6P6R8h0pw@mail.gmail.com>
In-Reply-To: <CAA4WUYgvC_EbEkhMFsH_KuK3U5O=csGAFKmdw1XVn6P6R8h0pw@mail.gmail.com>
Accept-Language: en-US, fr-FR
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.20.6.135]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Received-SPF: none client-ip=194.2.158.67; envelope-from=Herve.Ruellan@crf.canon.fr; helo=inari-msr.crf.canon.fr
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.432, RP_MATCHES_RCVD=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UVf1S-0001vz-Cz d32b126fceaec58af92b034464616dd9
X-Original-To: ietf-http-wg@w3.org
Subject: RE: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/6C71876BDCCD01488E70A2399529D5E516416A6B@ADELE.crf.canon.fr>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17599
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>


> -----Original Message-----
> From: willchan@google.com [mailto:willchan@google.com] On Behalf Of
> William Chan (???)
> Sent: vendredi 26 avril 2013 07:29
> To: Roberto Peon
> Cc: Martin Thomson; James Snell; HTTP Working Group
> Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
> 
> We have not proposed a reprioritization frame since there was some mild
> resistance before at the Tokyo interim meeting, although most of that
> concern was about the larger prioritization proposal and not strictly
> reprioritization. We promised to go get data and come back and report. We
> have not gotten said data yet (it's in progress), so I don't have much to report
> (no data, only status if people are interested. I'm inclined to wait until I have
> data). If reprioritization is not controversial, then we can go ahead and
> propose a frame for that and revisit the rest of the larger prioritization
> proposal when we have data.
> 
> As far as the priority being useless to send with push streams, the only
> reason I can see that as being useful is perhaps saving a reprioritization frame
> (meh) or if you have a "smart" server that's doing some learning process to
> decide how to prioritize push streams in absence of client information, then
> perhaps this would allow for informing the client as you're learning. That's a
> weak argument too because you can just log that information server side to
> evaluate your learning process.
> 
> Actually, if we don't strictly assume HTTP style client initiated
> request/response application protocol semantics, then at the framing layer
> with fully bidirectional streams, the server may be requesting that the client
> send data back to the server according to the server advisory priority. That is,
> since streams are bidirectional, you can imagine servers initiating a
> request/response pair.
> 
> Now, as to the push stream priority default, in general for a web browsing
> case, the "parent" stream will be the root document of a page load, and the
> push streams will be subresources, which should generally be lower priority
> than the root document. So I don't think priority inheritance is advisable for
> this scenario, and at least for the HTTP case, it's not really important since it's
> a server-side implementation detail - in absence of client advisory priorities,
> the server just sends streams in whatever order it wants. No need to spec a
> required default or anything, let server implementations innovate here. A
> reprioritization frame would enable the client to send advisory priorities here
> to better inform the server. And I would recommend we allow clients to do
> so.

My reading of this is that a server could set a priority on a pushed stream as an information for the client: the priority value is the priority selected by the server for the stream. Then, if the client is not happy with this server defined priority it could use a reprioritization frame to change the priority of the stream.

Hervé.