Re: Design Issue: PUSH_PROMISE and Stream Priority

James M Snell <jasnell@gmail.com> Sat, 27 April 2013 21:35 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 B249421F993F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.401
X-Spam-Level:
X-Spam-Status: No, score=-10.401 tagged_above=-999 required=5 tests=[AWL=0.198, BAYES_00=-2.599, 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 CA5kUvHxZCr7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:35:55 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2C421F992E for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 14:35:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWClu-0004Z6-Q1 for ietf-http-wg-dist@listhub.w3.org; Sat, 27 Apr 2013 21:35:06 +0000
Resent-Date: Sat, 27 Apr 2013 21:35:06 +0000
Resent-Message-Id: <E1UWClu-0004Z6-Q1@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 1UWClp-0003Lz-Nb for ietf-http-wg@listhub.w3.org; Sat, 27 Apr 2013 21:35:01 +0000
Received: from mail-ob0-f179.google.com ([209.85.214.179]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWClo-0003FF-T2 for ietf-http-wg@w3.org; Sat, 27 Apr 2013 21:35:01 +0000
Received: by mail-ob0-f179.google.com with SMTP id oi10so4420933obb.38 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 14:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=77QUissXd+Zh6eUVyCeeTVECs1H6dATINT44N6zjL9U=; b=kwc7yrKWMiWTpVN5Jcce8oU4osj0BTAlDmTKEyQ8ZDmMqbonBFFvuhuEifSxHKCKTV yzd/OXYykA5EnuMkIjNf+bGJfjkRWLZWR66ZT2/RPDTFw8ttdUZuQLkfD36sgV7dGPTU 8JT7XtsqLFfjwmdLE/qZsxYhA+aQ8O6PrrreyCShySTeLOmvDCjlVdYfBoJnIPbEf9k8 ppbS1ZOR9WNbmXFg18uHEA6el0XI9q976kUSLMlXOMYOiQ17ozsNB81XZsE/MoBtmuKK SCyjkkhnp3DzIyQnqbCRs0GW5WFalEjg3hFKAo0vhODDhPuNxkfCUbTl0Ov0n+52UF7r bjQg==
X-Received: by 10.60.92.41 with SMTP id cj9mr20802349oeb.31.1367098474880; Sat, 27 Apr 2013 14:34:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Sat, 27 Apr 2013 14:34:14 -0700 (PDT)
In-Reply-To: <CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@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>
From: James M Snell <jasnell@gmail.com>
Date: Sat, 27 Apr 2013 14:34:14 -0700
Message-ID: <CABP7RbcP823BV0GXXcqdQScUeP3o6rXeGzCkYzAxm9mFoU-LBg@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.214.179; envelope-from=jasnell@gmail.com; helo=mail-ob0-f179.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.741, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UWClo-0003FF-T2 06e7b27824e2829d26488aeaf94e5590
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CABP7RbcP823BV0GXXcqdQScUeP3o6rXeGzCkYzAxm9mFoU-LBg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17637
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>

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.
>> >>
>> >
>
>