Re: Design Issue: PUSH_PROMISE and Stream Priority
William Chan (陈智昌) <willchan@chromium.org> Fri, 26 April 2013 05:30 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 7269C21F97AB for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 22:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.676
X-Spam-Level:
X-Spam-Status: No, score=-9.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 EEn3bw9FGKsI for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 25 Apr 2013 22:30:38 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 48F3021F97BB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 25 Apr 2013 22:30:38 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UVbE3-0006T6-Ua for ietf-http-wg-dist@listhub.w3.org; Fri, 26 Apr 2013 05:29:39 +0000
Resent-Date: Fri, 26 Apr 2013 05:29:39 +0000
Resent-Message-Id: <E1UVbE3-0006T6-Ua@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVbDy-0006SM-3D for ietf-http-wg@listhub.w3.org; Fri, 26 Apr 2013 05:29:34 +0000
Received: from mail-qe0-f46.google.com ([209.85.128.46]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <willchan@google.com>) id 1UVbDx-00014I-7G for ietf-http-wg@w3.org; Fri, 26 Apr 2013 05:29:34 +0000
Received: by mail-qe0-f46.google.com with SMTP id nd7so2254252qeb.5 for <ietf-http-wg@w3.org>; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5rLNmx7SnUh8GGvFG8a2xmlTV6DAZBxnYhR/o1Uc4ro=; b=dVktk6vxTcYnQkwZM3iinKo5PzjFHawA7Y7KXaS/VNAlEUeqQSHVI7b2kMkq138TR/ Ni5LTiVAopoXTn2MGkM684KT1yb+UglxWVVCjmgYkl5LBvBQqGwx3jCTyAAKGc0NKV3x qsLzaclPJONsf760pdngrselppdwMVIQvLBwsSiH5JvwQHUcd89b++BmgvgG/yJ4Pxnw lbgWxi7pjf1nN1wZP2oKk1pMFN9uYNcG4G/OYhQT8uZaau6p71okTmD40EHUiABG3F6T necizptZktTbUtiA0kWXl71oxVQkBOhwkhUAf4FYYTWQXQcva4RFkOAiptKzKvVzthBk gu9Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5rLNmx7SnUh8GGvFG8a2xmlTV6DAZBxnYhR/o1Uc4ro=; b=DL/+2X2w9H635+aOhRFHHtLeubDPLGp1RtMyiXxubcoRt2xFG4PZYimYQMNhRTPpX3 Zq/qHBPgC+rhmQY7+2zwbzEswVWKlyflJRvR8c/KPH8YfEUiD7wmCkpoawqu866lz3sg +DVYLgex7xHMip0PQwaAAZUYfs+OnRAJ9Q6XM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=5rLNmx7SnUh8GGvFG8a2xmlTV6DAZBxnYhR/o1Uc4ro=; b=eroOnrucniLICAG+dgnCECO8z0D87yIVMHSASTRChSppEeEbTjg+c6WawubNHgwCtA tg4giQtHg8MupX5WTcobvKYHrHwrE8BxyN95BHAD6At7v81M6zvY3Cg57Kn12jzwzs3k YehCQI55rQJ+TTMyCfjAvLDxxCt5JIitOxmA/gIGReYGLF487+YKmmaju7VkYAAvIx5h E0aonl7zV8bHzyrhblJYwI6bynnxW10l62Gl0wMKqguzVCAKwflVMTgoR7H3UAjuY6H7 S4OJLohfDGUyFbpYxzDTqBJX/Wl/eQ1WOiDDy/cZGpzQnkJHRUirlzUB7PMBpmTaof4u 6zIg==
MIME-Version: 1.0
X-Received: by 10.49.3.6 with SMTP id 6mr17271180qey.64.1366954147491; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
Sender: willchan@google.com
Received: by 10.229.180.4 with HTTP; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
In-Reply-To: <CAP+FsNdxCcs+J3nhFE6nusAsZLwSG=WMEhHZK0FZjgQQVveHAw@mail.gmail.com>
References: <CABP7Rbf_hZ036vUs4LNTrGQ91kft2_97aV-9Gi2KVJnUJphbNA@mail.gmail.com> <CABkgnnUBEvDtNQM8G5vyfyqRz4tQ8su9+14gMTdaXhzY2cq+Kg@mail.gmail.com> <CAP+FsNdxCcs+J3nhFE6nusAsZLwSG=WMEhHZK0FZjgQQVveHAw@mail.gmail.com>
Date: Thu, 25 Apr 2013 22:29:07 -0700
X-Google-Sender-Auth: OEOeADqSq9X80kFAsVtJpteAKwg
Message-ID: <CAA4WUYgvC_EbEkhMFsH_KuK3U5O=csGAFKmdw1XVn6P6R8h0pw@mail.gmail.com>
From: "William Chan (陈智昌)" <willchan@chromium.org>
To: Roberto Peon <grmocg@gmail.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, James Snell <jasnell@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="047d7bdc0aba63071504db3cd0b0"
X-Gm-Message-State: ALoCoQlYDeADNdHWeMIJcRE73XlpHV4NRUrORSSxnYFRsKSdFJhOXf2JKj6BX0S9HO2C12yygcQs3wHtOmDGBRwT3DGA8cKk5b3R/fAobeL6Yav+tN2AJ75cIyidr7CVdnpvfaGdnZeUQQ/HBoZ6AY3r3nwVODzSdlskz294L6dEocNrSuFcA6p0rVuBeP8sXcQpmgzw5jiK
Received-SPF: pass client-ip=209.85.128.46; envelope-from=willchan@google.com; helo=mail-qe0-f46.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-2.687, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UVbDx-00014I-7G dfa373039a422e43447afaee639120cb
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <http://www.w3.org/mid/CAA4WUYgvC_EbEkhMFsH_KuK3U5O=csGAFKmdw1XVn6P6R8h0pw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17596
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>
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. 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. 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