Re: Design Issue: PUSH_PROMISE and Stream Priority

James M Snell <jasnell@gmail.com> Fri, 26 April 2013 07:13 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 72AA321F97A7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 00:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.232
X-Spam-Level:
X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 eKcAcBpNENZn for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 26 Apr 2013 00:13:49 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 352D621F979F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 26 Apr 2013 00:13:49 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVcqG-0001jU-Gl for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 07:13:12 +0000
Resent-Date: Fri, 26 Apr 2013 07:13:12 +0000
Resent-Message-Id: <E1UVcqG-0001jU-Gl@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 1UVcqA-0001if-8G for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 07:13:06 +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 1UVcq8-0006BD-My for ietf-http-wg@w3.org; Fri, 26 Apr 2013 07:13:06 +0000
Received: by mail-ob0-f179.google.com with SMTP id oi10so3211638obb.10 for <ietf-http-wg@w3.org>; Fri, 26 Apr 2013 00:12:38 -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:content-type; bh=kemE9ZMIDWtVQ6RwOcBJ0dDkg3mjoTa77f/BjT/XgA4=; b=Nq/LI5NsKZTII3dAsgOi5UTYJczFhUmCOODOJVKeYeYt2chN2d3b5tJHaC2GdGKtle H8kDzxzLe4bh7T/1EKoM/x/Dflea30lMDDoY+O3nPXVxZ3eqWNvQWSrMBB9ibOXKyxPe Aq+SZyO8TdK/5zzRNe/+Y3u+C7Zc56SWFJuS8a1afRmqBGONGownA5bIrHelCGYw0bkg Ty8hux22IwpZ/ugGqUm31bDfMCYxrmDIbm6Erq9sFxieU2E547qgn0CXXaN6X1o7b0fE c5YqZdqyfpbm65wuFH7NQcb1zcHNaWC3LnO/pgQBwjN6A7s4JCIu6XvVM4kBaVdLOW8S 62eg==
MIME-Version: 1.0
X-Received: by 10.60.47.84 with SMTP id b20mr2922285oen.135.1366960358783; Fri, 26 Apr 2013 00:12:38 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Fri, 26 Apr 2013 00:12:38 -0700 (PDT)
Received: by 10.60.3.137 with HTTP; Fri, 26 Apr 2013 00:12:38 -0700 (PDT)
In-Reply-To: <CABP7RbdrR6YtMZYiEDWoOEFHXaF5tC=-oHp6DeAw7q8ri4TaiA@mail.gmail.com>
References: <CABP7Rbf_hZ036vUs4LNTrGQ91kft2_97aV-9Gi2KVJnUJphbNA@mail.gmail.com> <CABkgnnUBEvDtNQM8G5vyfyqRz4tQ8su9+14gMTdaXhzY2cq+Kg@mail.gmail.com> <CAP+FsNdxCcs+J3nhFE6nusAsZLwSG=WMEhHZK0FZjgQQVveHAw@mail.gmail.com> <CAA4WUYgvC_EbEkhMFsH_KuK3U5O=csGAFKmdw1XVn6P6R8h0pw@mail.gmail.com> <CABP7RbdrR6YtMZYiEDWoOEFHXaF5tC=-oHp6DeAw7q8ri4TaiA@mail.gmail.com>
Date: Fri, 26 Apr 2013 00:12:38 -0700
Message-ID: <CABP7Rbekzz=gy25yjp70bwTG4PfEuEkSPzJtP51-sDMdc1dqgA@mail.gmail.com>
From: James M Snell <jasnell@gmail.com>
To: =?UTF-8?B?Q2hhbldpbGxpYW0o6ZmI5pm65piMKQ==?= <willchan@chromium.org>, ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary=001a11c20b449b824b04db3e429c
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.749, 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 1UVcq8-0006BD-My bf5b1891a2711e057c4c0b3e17f0ccdc
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CABP7Rbekzz=gy25yjp70bwTG4PfEuEkSPzJtP51-sDMdc1dqgA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17598
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>

My apologies,  i accidentally excluded the list in this reply.
On Apr 26, 2013 12:11 AM, "James M Snell" <jasnell@gmail.com>; wrote:

>
> On Apr 25, 2013 10:29 PM, "William Chan (陈智昌)" <willchan@chromium.org>;
> wrote:
> >
> > We have not proposed a reprioritization frame since there was some mild
> resistance before at the Tokyo interim meeting, although most of that
> concern was about the larger prioritization proposal and not strictly
> reprioritization. We promised to go get data and come back and report. We
> have not gotten said data yet (it's in progress), so I don't have much to
> report (no data, only status if people are interested. I'm inclined to wait
> until I have data). If reprioritization is not controversial, then we can
> go ahead and propose a frame for that and revisit the rest of the larger
> prioritization proposal when we have data.
> >
>
> Waiting for the data is fine. I'm not opposed to a prioritization frame
> but I worry about creating too many special purpose frame types at too fine
> gained a level. We'll need to be careful.
>
> > As far as the priority being useless to send with push streams, the only
> reason I can see that as being useful is perhaps saving a reprioritization
> frame (meh) or if you have a "smart" server that's doing some learning
> process to decide how to prioritize push streams in absence of client
> information, then perhaps this would allow for informing the client as
> you're learning. That's a weak argument too because you can just log that
> information server side to evaluate your learning process.
> >
> > Actually, if we don't strictly assume HTTP style client initiated
> request/response application protocol semantics, then at the framing layer
> with fully bidirectional streams, the server may be requesting that the
> client send data back to the server according to the server advisory
> priority. That is, since streams are bidirectional, you can imagine servers
> initiating a request/response pair.
> >
>
> This hits the core of the problem.. Are we creating a general purpose
> bidirectional framing protocol that we can layer http onto or are we
> creating a new http based on frames.  If the former, then push stream
> priority may make sense.  If the latter, it could be dangerous and
> completely unnecessary.
>
> For now, let's just say that only client initiated streams have a
> priority. Doing so eliminates many potentially messy issues.  If someone
> wants to experiment with prioritized push streams later on down the road ,
> they can do so.
>
> - James
>
> > Now, as to the push stream priority default, in general for a web
> browsing case, the "parent" stream will be the root document of a page
> load, and the push streams will be subresources, which should generally be
> lower priority than the root document. So I don't think priority
> inheritance is advisable for this scenario, and at least for the HTTP case,
> it's not really important since it's a server-side implementation detail -
> in absence of client advisory priorities, the server just sends streams in
> whatever order it wants. No need to spec a required default or anything,
> let server implementations innovate here. A reprioritization frame would
> enable the client to send advisory priorities here to better inform the
> server. And I would recommend we allow clients to do so.
> >
> >
> >
> >
> > On Thu, Apr 25, 2013 at 7:36 PM, Roberto Peon <grmocg@gmail.com>; wrote:
> >>
> >> I am traveling but should be back by Monday. I'll be slow before then
> as I'm having to type in the phone.
> >>
> >> On Apr 25, 2013 6:50 PM, "Martin Thomson" <martin.thomson@gmail.com>;
> wrote:
> >>>
> >>> Good point.  The hope was that a reprioritization frame would be
> >>> proposed (Will, Roberto, we're all still waiting).
> >>>
> >>> If that's enough, then adding a default (maybe 2^30) would fix this.
> >>>
> >>> On 25 April 2013 11:03, James M Snell <jasnell@gmail.com>; wrote:
> >>> > https://github.com/http2/http2-spec/issues/75
> >>> >
> >>> > The current draft (-02) says, "The endpoint establishing a new stream
> >>> > can assign a priority for the stream."
> >>> >
> >>> > However, the spec does not define how a stream established using
> >>> > PUSH_PROMISE can assign the priority for a stream, nor does the spec
> >>> > discuss whether the notion of stream priority applies to push
> streams.
> >>> >
> >>> > The spec currently states that PUSH_PROMISE is followed later on by a
> >>> > HEADERS frame.
> >>> >
> >>> > If priority applies to push streams, then we need to add that
> priority
> >>> > can be assigned by allowing the use of a HEADERS+PRIORITY frame.
> >>> > Otherwise, we need to clarify the spec text to say that push streams
> >>> > have no priority.
> >>> >
> >>>
> >
>