Return-Path: 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 AD97F21F856D for ; Sat, 25 May 2013 12:35:46 -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 LhizKygNDsLF for ; Sat, 25 May 2013 12:35:40 -0700 (PDT) Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 256E121F8506 for ; Sat, 25 May 2013 12:35:40 -0700 (PDT) Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from ) id 1UgKEa-0005QT-Gk for ietf-http-wg-dist@listhub.w3.org; Sat, 25 May 2013 19:34:32 +0000 Resent-Date: Sat, 25 May 2013 19:34:32 +0000 Resent-Message-Id: Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from ) id 1UgK5g-0002uZ-NU for ietf-http-wg@listhub.w3.org; Sat, 25 May 2013 19:25:20 +0000 Received: from mail-oa0-f51.google.com ([209.85.219.51]) by lisa.w3.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from ) id 1UgK5Z-0002mB-Lu for ietf-http-wg@w3.org; Sat, 25 May 2013 19:25:20 +0000 Received: by mail-oa0-f51.google.com with SMTP id f4so7522203oah.10 for ; Sat, 25 May 2013 12:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xcGLvwOdm6Et7icF3hgMAshzUylBLQk1pSg8ZlsXa3Q=; b=UavEKol5bOJsDAnjDHRXt0JATiyGHH0CCwDs0dHMeVdo+9gOPtiiGeCiZUpoZV/8G1 wm2AJNo+CO6YCparmZgAIQPYRr20D+6abdp81iu1bEZ8Fr3XDwwZYmUYA+WqoUbZ4cJw YwkoUmmT9Q4OHMeHaKv7OfiRHlhtUpCo5gz3amoDzi5DMfobWNLo3Ggjd2IAAZvj+Aq/ PFHSiDtrrH7Xa+5t24kS4iXXWz2uVOhlVQo7u4NPf0cMG+ih8iueru6cikr1lqKQDUZu mDxhVvXcDUb71lxWOOGET58Q0sYmpTXoJ9kgUPJf//rS3VYeTOlZnduGPBclpgQTZwyf V6jA== MIME-Version: 1.0 X-Received: by 10.182.118.42 with SMTP id kj10mr14762067obb.99.1369509887766; Sat, 25 May 2013 12:24:47 -0700 (PDT) Received: by 10.76.131.232 with HTTP; Sat, 25 May 2013 12:24:47 -0700 (PDT) In-Reply-To: References: Date: Sat, 25 May 2013 12:24:47 -0700 Message-ID: From: Roberto Peon To: Jeff Pinner Cc: James M Snell , =?UTF-8?B?V2lsbGlhbSBDaGFuICjpmYjmmbrmmIwp?= , Patrick McManus , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary=f46d0447878d6077fd04dd8fde20 Received-SPF: pass client-ip=209.85.219.51; envelope-from=grmocg@gmail.com; helo=mail-oa0-f51.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, 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 1UgK5Z-0002mB-Lu 8c48c29a135f8ebe92b94d3d32e070cb X-Original-To: ietf-http-wg@w3.org Subject: Re: Design Issue: Separate HEADERS and PRIORITY Frames, Eliminate HEADERS+PRIORITY Archived-At: Resent-From: ietf-http-wg@w3.org X-Mailing-List: archive/latest/18090 X-Loop: ietf-http-wg@w3.org Resent-Sender: ietf-http-wg-request@w3.org Precedence: list List-Id: List-Help: List-Post: List-Unsubscribe: --f46d0447878d6077fd04dd8fde20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right now, we've proposed the following frame types: HEADERS+PRIORITY HEADERS PRIORITY (to be added) While I'm strongly against removal for the HEADERS+PRIORITY frame, I do agree that the PRIORITY frame is probably reasonable. Playing devil's advocate on the PRIORTY frame, though, I ask myself the question: Since a HEADERS+PRIORITY frame with no payload would be the same as a PRIORTY frame (and we have to handle the empty-payload case for header blocks anyway), are we buying anything? I don't have a good answer except that the PRIORITY frame "smells" right, and it has a low implementation cost in terms of complexity if we're doing any reprioritization. So, onto why I hate the idea of *requiring* separate frames for PRIORITY and HEADERS: In the PUSH_PROMISE case, the client can have indicated that it will not accept these streams by sending a SETTINGS frame, and much of the time the client has orders of magnitude more memory to spend per connection that does the server. PUSH_PROMISE is a totally different beast from PRIORITY. PRIORITY, on the other hand is not optional and can't be disabled-- if we did remove/disallow it, then we'd have crippled multiplexing for the browser use-case. If we allow PRIORITY to perform allocations, then we've increased complexity in the servers (more state transitions and state to store) and thus increased the number of DoS vectors against the servers for essentially zero gain. In your (non browser) use case, you'd just use HEADERS to initiate a stream from the client when you don't care to set the priority. You don't have to use HEADERS+PRIORITY. Your overall complexity should be unchanged. In the browser use-case, HEADERS+PRIORITY would be used nearly all the time, since the communication of priority is of very high importance (else the browser must implement and play heuristic waiting games for requests). In either case a PRIORITY frame could be used to reprioritize a stream. -=3DR On Sat, May 25, 2013 at 11:58 AM, Jeff Pinner wrote: > The color of my shed: > > I would like to see us remove HEADERS+PRIORITY entirely and add a separat= e > PRIORITY frame. > > I don't agree that separating them will simply cause an additional 4 byte= s > to be sent on every request. While it might be true that most browsers wi= ll > set the priority of a request, I don't think that all clients necessarily > will (I have a mobile client that uses HTTP for API requests and have not > found the priority mechanism necessary -- at least not yet). > > I could imagine that it would be acceptable to send the PRIORITY frame > before the HEADERS frame and still mandate that HEADERS frames (and now > only HEADERS frames) initiate streams. While this does cause some extra > state allocation, we already have to do something similar with PUSH_PROMI= SE > where we must track that the "stream identifier MUST be a valid choice fo= r > the next stream sent" and then initiate the stream later. > > This would also give us a mechanism to send priority changes for > outstanding requests at the framing layer, and could allow priorities to = be > set for pushed responses should it prove useful. > > - Jeff > > > On Tue, May 21, 2013 at 2:55 PM, James M Snell wrote: > >> On Tue, May 21, 2013 at 2:43 PM, Roberto Peon wrote: >> > Sending the PRIORITY frame *MUST* cause state allocation at the >> receiver, >> > else it was useless to send before the HEADERS frame. As you point out= , >> at >> > minimum it must allocate a stream ID and priority field, and for most >> > implementations it will also need to include so mechanism of pointing >> out >> > that the headers don't exist, so, probably between 16 to 24 bytes wort= h >> of >> > allocation on a 64 bit machine. >> > >> >> Sorry, I wasn't clear in my initial response. Yes, there is some state >> that would need to be allocated but not the same as that when the >> initial HEADERS frame is received, for instance. >> >> > If the PRIORITY frame was renamed to CHANGE_PRIORITY, would that clari= fy >> > anything? Priority changing is the current intent of that frame type. >> > >> >> Not particularly, because we'd still have the question of when to use >> HEADERS+PRIORITY vs. the combination of HEADERS and a CHANGE_PRIORITY. >> Can HEADERS+PRIORITY be used any time? For instance, could I send an >> initial HEADERS frame on a stream then later send a HEADERS+PRIORITY >> on the same stream? I honestly don't care how it ultimately ends up so >> long as (a) It's the simplest thing that could possibly work and (b) >> Is easy to explain in the spec and easy for a developer to implement. >> >> > btw, I am not particularly partial to the "any frame opening up a >> stream" >> > thing. I'm not completely against it though :) >> > My reason for slightly preferring that streams must begin with HEADERS >> or >> > HEADERS+PRIORITY is that it is an explicit statement of intent, and th= us >> > off-by-one, uninitialized var, etc. errors are more likely to be >> detectable >> > in a world where such is required. >> > >> >> I would very much like to see us mandate that streams always initiate >> with a HEADERS / HEADERS+PRIORITY frame. >> >> - James >> >> > >> > >> > -=3DR >> > >> > >> > On Tue, May 21, 2013 at 2:19 PM, James M Snell >> wrote: >> >> >> >> On Tue, May 21, 2013 at 10:30 AM, William Chan (=E9=99=88=E6=99=BA=E6= =98=8C) >> >> wrote: >> >> > Thanks for describing these cases now. I had not thought of them. >> >> > >> >> > If everyone's sold on reprioritization, then let's go ahead and do >> this >> >> > and >> >> > have the debate about ditching HEADERS+PRIORITY or not. I want to >> keep >> >> > it. I >> >> > don't like the idea of sending a PRIORITY frame first. Is sending a >> >> > PRIORITY >> >> > frame going to trigger stream state allocation at the receiver? >> What's >> >> > the >> >> > expectation? And if you don't have a priority for the HEADERS, then >> you >> >> > have >> >> > the race that Roberto described. >> >> > >> >> >> >> There is no reason to assume that sending a PRIORITY frame first woul= d >> >> trigger stream state allocation at the receiver. At most, it would >> >> reserve the stream ID and store the priority value. The full state >> >> allocation would not occur until the HEADERS frame is received. That >> >> said, I'm not 100% dead set on removing HEADERS+PRIORITY, I would jus= t >> >> like to simplify the protocol where it makes sense to, and even then >> >> only after it's been proven out in implementation. Having separate >> >> HEADERS, HEADERS+PRIORITY and PRIORITY frames is confusing, if we can >> >> do without separating them, we ought to do so. >> >> >> >> - James >> >> >> >> > >> >> > On Tue, May 21, 2013 at 2:09 PM, Patrick McManus < >> pmcmanus@mozilla.com> >> >> > wrote: >> >> >> >> >> >> >> >> >> On Tue, May 21, 2013 at 12:32 PM, William Chan (=E9=99=88=E6=99=BA= =E6=98=8C) >> >> >> wrote: >> >> >>> >> >> >>> >> >> >>> I support adding a new additional PRIORITY frame for stream >> >> >>> reprioritization. >> >> >> >> >> >> >> >> >> me too. Specifically I support this as a mechanism for the client >> to be >> >> >> able to explicitly prioritize an open pushed stream. I can wait fo= r >> >> >> more >> >> >> evidence about re-prioritizing, but in cases where the client hasn= 't >> >> >> ever >> >> >> explicitly set the stream's priority I think we have evidence that >> its >> >> >> time >> >> >> to do something. >> >> >>> >> >> >>> >> >> >>> Unless there's a reason this needs to be in the current http/2 >> draft >> >> >>> sooner rather than later, I'd rather punt on this discussion unti= l >> we >> >> >>> have >> >> >>> implementation experience that can guide this debate. >> >> >> >> >> >> >> >> >> I think there is experience here specifically related to push. >> >> >> >> >> >> e.g. You can easily configure mod_spdy to push images when html is >> >> >> pulled. >> >> >> but you can't effectively dictate the relative priorities of those >> two >> >> >> things. >> >> >> >> >> >> Sure, you can define an explicit priority for those images but >> priority >> >> >> implementations are all about relative levels and the client set t= he >> >> >> priority of the html. >> >> >> >> >> >> You can argue that mod_spdy should have defined relative prioritie= s >> >> >> (+/- >> >> >> the associated stream) instead of constants.. that would be better >> but >> >> >> the >> >> >> client still has no way to make sure those streams are at a higher >> >> >> priority >> >> >> than a "save as" background stream (I've seen this one happen as >> >> >> mod_spdy >> >> >> defaults to lowest priority when pushing), or a lower priority tha= n >> a >> >> >> real-time video stream.. >> >> >> >> >> >> plus there is no scale for the server to work with.. it might set = a >> +2 >> >> >> priority for pushed images but the client might be using +3 for >> pulled >> >> >> images causing a mismatch in something that was intended to be >> equally >> >> >> weighted. >> >> >> >> >> >> at least with a priority frame the client can make those >> adjustments in >> >> >> a >> >> >> RTT. >> >> >> >> >> >> Cheefully, >> >> >> -Patrick >> >> >> >> >> >> >> >> > >> >> > >> >> >> > >> >> > --f46d0447878d6077fd04dd8fde20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right now, we've proposed the following fra= me types:

HEADERS+PRIORITY
HEADERS
PRIORITY (to be added)

While I'm strongly against removal for the HEADER= S+PRIORITY frame, I do agree that the PRIORITY frame is probably reasonable= .

Playing devil's advocate on the = PRIORTY frame, though, I ask myself the question:
Since a HEADERS+PRIORITY frame with no payload would be the same= as a PRIORTY frame (and we have to handle the empty-payload case for heade= r blocks anyway), are we buying anything?
I don't= have a good answer except that the PRIORITY frame "smells" right= , and it has a low implementation cost in terms of complexity if we're = doing any reprioritization.

So, onto why I hate the idea of *requiring*= separate frames for PRIORITY and HEADERS:
In the PUSH= _PROMISE case, the client can have indicated that it will not accept these = streams by sending a SETTINGS frame, and much of the time the client has or= ders of magnitude more memory to spend per connection that does the server.= PUSH_PROMISE is a totally different beast from PRIORITY.
PRIORITY, on the other hand is not optional and can't be disabled-= - if we did remove/disallow it, then we'd have crippled multiplexing fo= r the browser use-case.
If we allow PRIORITY to perform allocatio= ns, then we've increased complexity in the servers (more state transiti= ons and state to store) and thus increased the number of DoS vectors agains= t the servers for essentially zero gain.

In your (non browser) use case, you'd j= ust use HEADERS to initiate a stream from the client when you don't car= e to set the priority. You don't have to use HEADERS+PRIORITY. Your ove= rall complexity should be unchanged.
In the browser use-case, HEADERS+PRIORITY would be used nearly a= ll the time, since the communication of priority is of very high importance= (else the browser must implement and play heuristic waiting games for requ= ests).=C2=A0

In either case a PRIORITY frame could be us= ed to reprioritize a stream.

-=3DR
=


O= n Sat, May 25, 2013 at 11:58 AM, Jeff Pinner <jpinner@twitter.com&g= t; wrote:
The color of my shed:
<= br>
I would like to see us remove HEADERS+PRIORITY entirely and a= dd a separate PRIORITY frame.

I don't agree that separating them will simply caus= e an additional 4 bytes to be sent on every request. While it might be true= that most browsers will set the priority of a request, I don't think t= hat all clients necessarily will (I have a mobile client that uses HTTP for= API requests and have not found the priority mechanism necessary -- at lea= st not yet).

I could imagine that it would be acceptable to send the= PRIORITY frame before the HEADERS frame and still mandate that HEADERS fra= mes (and now only HEADERS frames) initiate streams. While this does cause s= ome extra state allocation, we already have to do something similar with PU= SH_PROMISE where we must track that the "stream identifier MUST be a v= alid choice for the next stream sent" and then initiate the stream lat= er.

This would also give us a mechanism to send priority ch= anges for outstanding requests at the framing layer, and could allow priori= ties to be set for pushed responses should it prove useful.

- Jeff
<= div class=3D"h5">


On Tue, May 21, 2013 at 2:55 PM, James M Snell <jasnell@gmail.com&= gt; wrote:
On Tue, May 21, 2013 at 2:43 PM, Robert= o Peon <grmocg@gma= il.com> wrote:
> Sending the PRIORITY frame *MUST* cause state allocation at the receiv= er,
> else it was useless to send before the HEADERS frame. As you point out= , at
> minimum it must allocate a stream ID and priority field, and for most<= br> > implementations it will also need to include so mechanism of pointing = out
> that the headers don't exist, so, probably between 16 to 24 bytes = worth of
> allocation on a 64 bit machine.
>

Sorry, I wasn't clear in my initial response. Yes, there is some = state
that would need to be allocated but not the same as that when the
initial HEADERS frame is received, for instance.

> If the PRIORITY frame was renamed to CHANGE_PRIORITY, would that clari= fy
> anything? Priority changing is the current intent of that frame type.<= br> >

Not particularly, because we'd still have the question of when to= use
HEADERS+PRIORITY vs. the combination of HEADERS and a CHANGE_PRIORITY.
Can HEADERS+PRIORITY be used any time? For instance, could I send an
initial HEADERS frame on a stream then later send a HEADERS+PRIORITY
on the same stream? I honestly don't care how it ultimately ends up so<= br> long as (a) It's the simplest thing that could possibly work and (b) Is easy to explain in the spec and easy for a developer to implement.

> btw, I am not particularly partial to the "any frame opening up a= stream"
> thing. I'm not completely against it though :)
> My reason for slightly preferring that streams must begin with HEADERS= or
> HEADERS+PRIORITY is that it is an explicit statement of intent, and th= us
> off-by-one, uninitialized var, etc. errors are more likely to be detec= table
> in a world where such is required.
>

I would very much like to see us mandate that streams always initiate=
with a HEADERS / HEADERS+PRIORITY frame.

- James

>
>
> -=3DR
>
>
> On Tue, May 21, 2013 at 2:19 PM, James M Snell <jasnell@gmail.com> wrote:
>>
>> On Tue, May 21, 2013 at 10:30 AM, William Chan (=E9=99=88=E6=99=BA= =E6=98=8C)
>> <wil= lchan@chromium.org> wrote:
>> > Thanks for describing these cases now. I had not thought of t= hem.
>> >
>> > If everyone's sold on reprioritization, then let's go= ahead and do this
>> > and
>> > have the debate about ditching HEADERS+PRIORITY or not. I wan= t to keep
>> > it. I
>> > don't like the idea of sending a PRIORITY frame first. Is= sending a
>> > PRIORITY
>> > frame going to trigger stream state allocation at the receive= r? What's
>> > the
>> > expectation? And if you don't have a priority for the HEA= DERS, then you
>> > have
>> > the race that Roberto described.
>> >
>>
>> There is no reason to assume that sending a PRIORITY frame first w= ould
>> trigger stream state allocation at the receiver. At most, it would=
>> reserve the stream ID and store the priority value. The full state=
>> allocation would not occur until the HEADERS frame is received. Th= at
>> said, I'm not 100% dead set on removing HEADERS+PRIORITY, I wo= uld just
>> like to simplify the protocol where it makes sense to, and even th= en
>> only after it's been proven out in implementation. Having sepa= rate
>> HEADERS, HEADERS+PRIORITY and PRIORITY frames is confusing, if we = can
>> do without separating them, we ought to do so.
>>
>> - James
>>
>> >
>> > On Tue, May 21, 2013 at 2:09 PM, Patrick McManus <pmcmanus@mozilla.com= >
>> > wrote:
>> >>
>> >>
>> >> On Tue, May 21, 2013 at 12:32 PM, William Chan (=E9=99=88= =E6=99=BA=E6=98=8C)
>> >> <willchan@chromium.org> wrote:
>> >>>
>> >>>
>> >>> I support adding a new additional PRIORITY frame for = stream
>> >>> reprioritization.
>> >>
>> >>
>> >> me too. Specifically I support this as a mechanism for th= e client to be
>> >> able to explicitly prioritize an open pushed stream. I ca= n wait for
>> >> more
>> >> evidence about re-prioritizing, but in cases where the cl= ient hasn't
>> >> ever
>> >> explicitly set the stream's priority I think we have = evidence that its
>> >> time
>> >> to do something.
>> >>>
>> >>>
>> >>> Unless there's a reason this needs to be in the c= urrent http/2 draft
>> >>> sooner rather than later, I'd rather punt on this= discussion until we
>> >>> have
>> >>> implementation experience that can guide this debate.=
>> >>
>> >>
>> >> I think there is experience here specifically related to = push.
>> >>
>> >> e.g. You can easily configure mod_spdy to push images whe= n html is
>> >> pulled.
>> >> but you can't effectively dictate the relative priori= ties of those two
>> >> things.
>> >>
>> >> Sure, you can define an explicit priority for those image= s but priority
>> >> implementations are all about relative levels and the cli= ent set the
>> >> priority of the html.
>> >>
>> >> You can argue that mod_spdy should have defined relative = priorities
>> >> (+/-
>> >> the associated stream) instead of constants.. that would = be better but
>> >> the
>> >> client still has no way to make sure those streams are at= a higher
>> >> priority
>> >> than a "save as" background stream (I've se= en this one happen as
>> >> mod_spdy
>> >> defaults to lowest priority when pushing), or a lower pri= ority than a
>> >> real-time video stream..
>> >>
>> >> plus there is no scale for the server to work with.. it m= ight set a +2
>> >> priority for pushed images but the client might be using = +3 for pulled
>> >> images causing a mismatch in something that was intended = to be equally
>> >> weighted.
>> >>
>> >> at least with a priority frame the client can make those = adjustments in
>> >> a
>> >> RTT.
>> >>
>> >> Cheefully,
>> >> -Patrick
>> >>
>> >>
>> >
>> >
>>
>



--f46d0447878d6077fd04dd8fde20--