Re: Design Issue: PUSH_PROMISE and Stream Priority

James M Snell <jasnell@gmail.com> Sat, 27 April 2013 20:32 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 339FB21F98DB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 13:32:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.384
X-Spam-Level:
X-Spam-Status: No, score=-10.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 QuNoNr55iyxV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 13:32:07 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8B15221F98D5 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 13:32:07 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWBmI-0003DS-1B for ietf-http-wg-dist@listhub.w3.org; Sat, 27 Apr 2013 20:31:26 +0000
Resent-Date: Sat, 27 Apr 2013 20:31:26 +0000
Resent-Message-Id: <E1UWBmI-0003DS-1B@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWBmD-0003Cc-79 for ietf-http-wg@listhub.w3.org; Sat, 27 Apr 2013 20:31:21 +0000
Received: from mail-oa0-f52.google.com ([209.85.219.52]) by maggie.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <jasnell@gmail.com>) id 1UWBmC-0002SM-Ec for ietf-http-wg@w3.org; Sat, 27 Apr 2013 20:31:21 +0000
Received: by mail-oa0-f52.google.com with SMTP id n12so5063300oag.11 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 13:30:54 -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=MSiW5AP6syqyjUy7gUaxdhBrhSgpLIGC0n+aaVSrku8=; b=joMu495mDc4IKwjLSzaa5RbYVfFEzJNMW6GxxId6m2ebhhWyAUm93Os7tBqicCFvBy /izh5Ju0ba8N+6ZUS+hvkf2qkV0rWgJpGrh8N4aCfbRTh5KheSfakUePt8BVqvQx8Ny1 hc2XWYixZJpR+VLPD/9wMsN8qWLDHu1jmw3bkDZpCjuU+Wv8WOkYVX6sboz1BQPJStoB 8TZauzQRjVb3peDserUrCTdrKhn2GhdccXSj0JIw9b1SayoCLc8HgvDBRPFikVl5JTDg ESS3+OYwe6k3lYJjeJM0nGM/yf9Yx2nYsA+SzDnI4SlF902acQbcRZaZqABdr4qc6xRZ PgBA==
X-Received: by 10.60.47.84 with SMTP id b20mr6223501oen.135.1367094654238; Sat, 27 Apr 2013 13:30:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.60.3.137 with HTTP; Sat, 27 Apr 2013 13:30:34 -0700 (PDT)
In-Reply-To: <CAP+FsNff96XihwzftWyp+B5givEUF5kqLA=qFd+=VjBG7P-OhA@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>
From: James M Snell <jasnell@gmail.com>
Date: Sat, 27 Apr 2013 13:30:34 -0700
Message-ID: <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@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.219.52; envelope-from=jasnell@gmail.com; helo=mail-oa0-f52.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.700, 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: maggie.w3.org 1UWBmC-0002SM-Ec aa578d6850cd88ac2d32b4fbbb83cb1c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17634
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 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.
>>
>