Re: Design Issue: PUSH_PROMISE and Stream Priority

William Chan (陈智昌) <> Fri, 26 April 2013 05:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7269C21F97AB for <>; Thu, 25 Apr 2013 22:30:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.676
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EEn3bw9FGKsI for <>; Thu, 25 Apr 2013 22:30:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 48F3021F97BB for <>; Thu, 25 Apr 2013 22:30:38 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UVbE3-0006T6-Ua for; Fri, 26 Apr 2013 05:29:39 +0000
Resent-Date: Fri, 26 Apr 2013 05:29:39 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UVbDy-0006SM-3D for; Fri, 26 Apr 2013 05:29:34 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UVbDx-00014I-7G for; Fri, 26 Apr 2013 05:29:34 +0000
Received: by with SMTP id nd7so2254252qeb.5 for <>; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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;; 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 with SMTP id 6mr17271180qey.64.1366954147491; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
Received: by with HTTP; Thu, 25 Apr 2013 22:29:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 25 Apr 2013 22:29:07 -0700
X-Google-Sender-Auth: OEOeADqSq9X80kFAsVtJpteAKwg
Message-ID: <>
From: =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= <>
To: Roberto Peon <>
Cc: Martin Thomson <>, James Snell <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary=047d7bdc0aba63071504db3cd0b0
X-Gm-Message-State: ALoCoQlYDeADNdHWeMIJcRE73XlpHV4NRUrORSSxnYFRsKSdFJhOXf2JKj6BX0S9HO2C12yygcQs3wHtOmDGBRwT3DGA8cKk5b3R/fAobeL6Yav+tN2AJ75cIyidr7CVdnpvfaGdnZeUQQ/HBoZ6AY3r3nwVODzSdlskz294L6dEocNrSuFcA6p0rVuBeP8sXcQpmgzw5jiK
Received-SPF: pass client-ip=;;
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: 1UVbDx-00014I-7G dfa373039a422e43447afaee639120cb
Subject: Re: Design Issue: PUSH_PROMISE and Stream Priority
Archived-At: <>
X-Mailing-List: <> archive/latest/17596
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 <> 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" <>
> 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 <> wrote:
>> >
>> >
>> > 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.
>> >