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: "ChanWilliam(陈智昌)" <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. > >>> > > >>> > > >
- Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority William Chan (陈智昌)
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- RE: Design Issue: PUSH_PROMISE and Stream Priority RUELLAN Herve
- RE: Design Issue: PUSH_PROMISE and Stream Priority RUELLAN Herve
- Re: Design Issue: PUSH_PROMISE and Stream Priority Patrick McManus
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Martin Thomson
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell
- Re: Design Issue: PUSH_PROMISE and Stream Priority Roberto Peon
- Re: Design Issue: PUSH_PROMISE and Stream Priority James M Snell