Re: Design Issue: PUSH_PROMISE and Stream Priority

James M Snell <jasnell@gmail.com> Sun, 28 April 2013 06:21 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 08B7A11E809C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 23:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.415
X-Spam-Level:
X-Spam-Status: No, score=-10.415 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 w+Gcp5+7QI6R for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 23:21:35 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id F227521F980B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 23:21:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWKz3-0000NE-SW for ietf-http-wg-dist@listhub.w3.org; Sun, 28 Apr 2013 06:21:13 +0000
Resent-Date: Sun, 28 Apr 2013 06:21:13 +0000
Resent-Message-Id: <E1UWKz3-0000NE-SW@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWKyx-0000M5-Ct for ietf-http-wg@listhub.w3.org; Sun, 28 Apr 2013 06:21:07 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWKyw-0002pR-Ax for ietf-http-wg@w3.org; Sun, 28 Apr 2013 06:21:07 +0000
Received: by mail-oa0-f52.google.com with SMTP id n12so5232272oag.11 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 23:20:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=2t0sFju91422Ay3B77GQRXkM572n8/tFtYxPF4bGwnI=; b=0Zs+GZMgn9vkbhCGL65IAYC3yU3J94rUrUKhs5Zcw5Gt/9dcGjku39T1QhjxwnsDhO Ti76aj+GhTfc6CSFF6lPvUkzTNkkEP/wH4SSxoRJ4GFYaUj947AEGEVTvYpjhj9hpOVM qwzfbv0UC4Dz+Mzg/pW0067+/TgCAtXdg84YDg6LA2huvPdBXHoRl5B0ZRnxpbuxLNXA PnDN/rDq5bmMnXLIvtbw0OrzvQ8gCq06xlPdPTNCLymZdgSgEZ7oeeFA0qXH/aklNIoU ytjKampm6gw8gk0v7zPthStptBP2RYpCWOEAEYqPuohmX6S8YLfTnnZaKh5F9m6A/Y4O UcXA==
MIME-Version: 1.0
X-Received: by 10.182.214.38 with SMTP id nx6mr6786950obc.77.1367130040490; Sat, 27 Apr 2013 23:20:40 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Sat, 27 Apr 2013 23:20:40 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Sat, 27 Apr 2013 23:20:40 -0700 (PDT)
In-Reply-To: <CAP+FsNc=chknK7oTpM3z1xrYVt5U5dvv=9FP2g8fSH0FDOq0eg@mail.gmail.com>
References: <CABP7Rbf_hZ036vUs4LNTrGQ91kft2_97aV-9Gi2KVJnUJphbNA@mail.gmail.com> <CABkgnnUBEvDtNQM8G5vyfyqRz4tQ8su9+14gMTdaXhzY2cq+Kg@mail.gmail.com> <CABP7RbccA=Zo2NVzJJ-8-G+y2cNt_j8rLr5YVfB_7CVOXLE_JQ@mail.gmail.com> <CABkgnnV64vRPcrdYGFcJQGZW_Wud5fKT76_z5BJc0NndsAEGYg@mail.gmail.com> <6C71876BDCCD01488E70A2399529D5E516416AC5@ADELE.crf.canon.fr> <CABP7RbcCesHYf8Q-9j22yg9=GGJWUooKKwBbJhBiyALzx3jWnw@mail.gmail.com> <CABkgnnVoc_s+x2Qu5HZz+OwkQaHhnNM57iYCLVH-QQO+g7vH7A@mail.gmail.com> <CAP+FsNff96XihwzftWyp+B5givEUF5kqLA=qFd+=VjBG7P-OhA@mail.gmail.com> <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@mail.gmail.com> <CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@mail.gmail.com> <CABP7RbcP823BV0GXXcqdQScUeP3o6rXeGzCkYzAxm9mFoU-LBg@mail.gmail.com> <CAP+FsNc=chknK7oTpM3z1xrYVt5U5dvv=9FP2g8fSH0FDOq0eg@mail.gmail.com>
Date: Sat, 27 Apr 2013 23:20:40 -0700
Message-ID: <CABP7RbeU+kMTgCpmAz4FPGvzOrzujQrC7Ya5ZOavN8GHVdM9dw@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, ietf-http-wg@w3.org, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8ff2425b6d3ba004db65c452
Received-SPF: pass client-ip=209.85.219.52; envelope-from=jasnell@gmail.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.724, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWKyw-0002pR-Ax 526206b0a0131ae76578d24cce1de99a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CABP7RbeU+kMTgCpmAz4FPGvzOrzujQrC7Ya5ZOavN8GHVdM9dw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17642
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>

Then let's just say that,  currently, setting and using the priority on
push streams is out of scope. If we later determine that it is something
worth doing, we can make it in scope.
On Apr 27, 2013 2:43 PM, "Roberto Peon" <grmocg@gmail.com>; wrote:

> There is a value, but I don't know if it is worth the 4 bytes. :)
> (The value is that now the client knows what the priority is, and has a
> better idea of when to change it if it is too far off from what it should
> be.)
> --=R
>
>
> On Sat, Apr 27, 2013 at 2:34 PM, James M Snell <jasnell@gmail.com>; wrote:
>
>> I believe we're saying the same thing in different ways. Given the
>> language *currently* in the spec, the initiator of a stream can
>> specify a priority value for that stream and the recipient of the
>> stream needs to try to process those streams accordingly. What I'm
>> saying is that there is absolutely no value in allowing the server to
>> specify a value for the priority on a stream.
>>
>> On Sat, Apr 27, 2013 at 2:27 PM, Roberto Peon <grmocg@gmail.com>; wrote:
>> > Sending of a message including a priority field != setting a priority.
>> >
>> > Server pushed streams have priority, but they are most likely to be set
>> by
>> > the client.
>> > I was understanding that we were asking a separate question: If it was
>> > worthwhile to have the server announce what priority it decided to use
>> for a
>> > pushed stream, and if so... when (e.g. at PUSH_PROMISE time, or, when
>> doing
>> > HEADERS).
>> >
>> > -=R
>> >
>> >
>> > On Sat, Apr 27, 2013 at 1:30 PM, James M Snell <jasnell@gmail.com>;
>> wrote:
>> >>
>> >> I honestly cannot imagine any scenario where it would be useful or
>> >> desirable to allow the server to set a priority for pushed streams. My
>> >> preference would be for us to say that only client-initiated streams
>> >> have a priority. If we want to leave the door open later on, we can
>> >> say that priority on server-initiated streams is undefined and out of
>> >> scope rather than saying it's not allowed at all.
>> >>
>> >> On Fri, Apr 26, 2013 at 11:46 AM, Roberto Peon <grmocg@gmail.com>;
>> wrote:
>> >> > Sorry I'm so slow-- internet connectivity is absolutely crud where I
>> am
>> >> > right now.
>> >> >
>> >> > What will the client do with the information a push_promise?
>> >> >  The headers, etc. are obvious--
>> >> > That data will prevent the client from creating another (redundant)
>> >> > request
>> >> > for the resource/
>> >> > If the client is given priority information with a push_promose,
>> perhaps
>> >> > this might cause the client to send a reprio message immediately to
>> >> > whatever
>> >> > the client wants, potentially before the server begins sending bytes
>> or
>> >> > creates the stream/reads the bytes. This assumes that the server even
>> >> > *knows* what the priority is at that point, which it may not.
>> >> >
>> >> > ... and, really, that is the only thing I can see the client doing
>> with
>> >> > that
>> >> > information. Does anyone see anything else it might do with it?
>> >> >
>> >> > does anyone think this is likely to be useful?
>> >> >
>> >> >
>> >> >
>> >> > On Fri, Apr 26, 2013 at 11:35 AM, Martin Thomson
>> >> > <martin.thomson@gmail.com>;
>> >> > wrote:
>> >> >>
>> >> >> On 26 April 2013 09:27, James M Snell <jasnell@gmail.com>; wrote:
>> >> >> > For this there are several possible solutions:
>> >> >> >
>> >> >> >     A. We can simply say PUSH_PROMISE streams have no priority.
>> >> >> >     B. We can say that PUSH_PROMISE streams inherit the priority
>> of
>> >> >> > their parent, client-initiated stream
>> >> >> >     C. We can allow the server to use HEADERS+PRIORITY or a new
>> >> >> > Reprioritization Frame to establish the priority of a pushed
>> stream.
>> >> >>
>> >> >> That seems like a fair taxonomy.
>> >> >>
>> >> >> A is not possible.  There is no such thing as no priority.  Default
>> >> >> priority, perhaps.  At the point that you have to contend with
>> >> >> choosing between two streams, then you have prioritization.
>> >> >>
>> >> >
>> >
>> >
>>
>
>