Re: Design Issue: PUSH_PROMISE and Stream Priority

Roberto Peon <grmocg@gmail.com> Sat, 27 April 2013 21:29 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 E870321F968D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[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 GRjEAHUGPNj5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECD821F9682 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 14:29:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWCfU-0008Df-2X for ietf-http-wg-dist@listhub.w3.org; Sat, 27 Apr 2013 21:28:28 +0000
Resent-Date: Sat, 27 Apr 2013 21:28:28 +0000
Resent-Message-Id: <E1UWCfU-0008Df-2X@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UWCfP-0008Cv-3L for ietf-http-wg@listhub.w3.org; Sat, 27 Apr 2013 21:28:23 +0000
Received: from mail-ob0-f178.google.com ([209.85.214.178]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UWCfO-0002yh-Ci for ietf-http-wg@w3.org; Sat, 27 Apr 2013 21:28:23 +0000
Received: by mail-ob0-f178.google.com with SMTP id 16so4494398obc.37 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 14:27:56 -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=akyOK4Jg/sx93PUhamRBDAPIWD/Ir5Z9eP6o2e+gL3A=; b=gOHO7S1FHpCnvk6m5ofSFtMjmezZ2TvKYGAct9JRc00A3gSY4kFEg/XH6R0w1REA9i Oi6OJ0QFzSEWENxigCvv0w3F/PpH1wQ2mb9UUTdCXsim/b9KsTrARmUkKlRn8H2x/B8m 1/6QLUlJPGz6vHTOr7LN8dyScqh9RErMrnKon9PWmOUwWwnDKnmfir1JsYT4wwtCdCvf C6uyeZPDJCAUcapk6GpqkFb09wnDKqn+I+8Prnf1Re8ONnL61xmTSicNjqP3bYtUvMwO absFyGFvsY4jHMr1FpLT+Lt9uCTBheziBq4yA6lFQBXDMM1PmuaHp/UOqqAJ6pcIVdMe TmuA==
MIME-Version: 1.0
X-Received: by 10.60.141.35 with SMTP id rl3mr26347161oeb.121.1367098076507; Sat, 27 Apr 2013 14:27:56 -0700 (PDT)
Received: by 10.76.12.103 with HTTP; Sat, 27 Apr 2013 14:27:56 -0700 (PDT)
In-Reply-To: <CABP7RbeMmCCVHPT5XxiTbrrRs4QBGeQfvMY1_YLasvpZnJMCYA@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>
Date: Sat, 27 Apr 2013 14:27:56 -0700
Message-ID: <CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@mail.gmail.com>
From: Roberto Peon <grmocg@gmail.com>
To: James M Snell <jasnell@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: multipart/alternative; boundary=047d7b339dbb3982f904db5e538f
Received-SPF: pass client-ip=209.85.214.178; envelope-from=grmocg@gmail.com; helo=mail-ob0-f178.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.735, 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 1UWCfO-0002yh-Ci 81c00feb4b2d8509fe55402a315d2597
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CAP+FsNepmuRb9ZaKa_zJiPfTJD_4VvX5RYos4RZvbBSaFjYV5g@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17636
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>

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