Re: Design Issue: PUSH_PROMISE and Stream Priority

Roberto Peon <grmocg@gmail.com> Sat, 27 April 2013 21:44 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 79FDB21F97D4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:44:02 -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 N2rkltPXokyi for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sat, 27 Apr 2013 14:44:01 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1691321F97D1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sat, 27 Apr 2013 14:44:01 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UWCu7-0006Rz-2Z for ietf-http-wg-dist@listhub.w3.org; Sat, 27 Apr 2013 21:43:35 +0000
Resent-Date: Sat, 27 Apr 2013 21:43:35 +0000
Resent-Message-Id: <E1UWCu7-0006Rz-2Z@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 1UWCu1-0006RJ-Vl for ietf-http-wg@listhub.w3.org; Sat, 27 Apr 2013 21:43:30 +0000
Received: from mail-oa0-f47.google.com ([209.85.219.47]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <grmocg@gmail.com>) id 1UWCu1-0003RO-6B for ietf-http-wg@w3.org; Sat, 27 Apr 2013 21:43:29 +0000
Received: by mail-oa0-f47.google.com with SMTP id n9so5095991oag.34 for <ietf-http-wg@w3.org>; Sat, 27 Apr 2013 14:43:03 -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=JdOXnd9HT5ShO2xX546mFsEJuHrOoIkvroNjoNjYZO0=; b=W79IC+MvmMA9xjDFOyzbaTb99qOzBOTBcHMbs4qppvXhHQ8TefKKcDzbMaDgfEei1K gUs12vDPI4Ahp65RMEswB+kh5PMk/VU/g01Br5i3/PYfbcPtRo1Ocg/ghSnuXrCT7vOp y82Lxi2wQCsvKbj75an6qrlGBPQ1P9W83MAihezUqbXZUZcbcCvU0UtznS6TcwlnHadd bHTXIZtMKn2n33ZBoghWDucsMReeKProRv5hBhPVfj3jZRCSALsnicGaGikNuR2IV6+w 34xeYyTiia/NzyF5Tzu+1Swy193zDONioYx3DAE29BASTaeJKyjKSdx4SOCsW8YcNN9v T22w==
MIME-Version: 1.0
X-Received: by 10.60.141.35 with SMTP id rl3mr26365293oeb.121.1367098983246; Sat, 27 Apr 2013 14:43:03 -0700 (PDT)
Received: by 10.76.12.103 with HTTP; Sat, 27 Apr 2013 14:43:03 -0700 (PDT)
In-Reply-To: <CABP7RbcP823BV0GXXcqdQScUeP3o6rXeGzCkYzAxm9mFoU-LBg@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>
Date: Sat, 27 Apr 2013 14:43:03 -0700
Message-ID: <CAP+FsNc=chknK7oTpM3z1xrYVt5U5dvv=9FP2g8fSH0FDOq0eg@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=047d7b339dbb45400f04db5e8925
Received-SPF: pass client-ip=209.85.219.47; envelope-from=grmocg@gmail.com; helo=mail-oa0-f47.google.com
X-W3C-Hub-Spam-Status: No, score=-4.4
X-W3C-Hub-Spam-Report: AWL=-1.726, 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 1UWCu1-0003RO-6B 652a6bc790983b109574104999886ca0
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+FsNc=chknK7oTpM3z1xrYVt5U5dvv=9FP2g8fSH0FDOq0eg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17639
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>

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