Re: SYN_REPLY

I agree with Roberto here. Please keep the priority in the SYN_STREAM and
don't split out into HEADERS with a followup PRIORITIZE. While HTTP/2 may
gain a reprioritization notion, not all APIs/protocols/systems will have
this. When a server receives a client stream initializing frame without a
priority, it won't know if/when the prioritization frame will arrive. It
may have to commit the stream to some arbitrary prioritization level, and
the system may not support reprioritization.

Also, if we omit the priority, then all streams need to start out with some
fixed priority level. This is so that there is a defined priority ordering
when one of the streams *does* get a PRIORITIZE frame for it, even if all
the other streams have not gotten any PRIORITIZE frames.

All in all, I'd rather keep the priority in the SYN_STREAM.


On Thu, Feb 21, 2013 at 4:39 PM, Roberto Peon <grmocg@gmail.com> wrote:

> s/resource/request.
> *sigh*
> -=R
>
>
> On Thu, Feb 21, 2013 at 4:38 PM, Roberto Peon <grmocg@gmail.com> wrote:
>
>> Browsers are *extremely* likely to use this, and they're where we're most
>> bandwidth constrained.
>> The goal is to allow the browsers to emit requests as soon as they're
>> encountered. I think that the resource types encountered often intermix, so
>> requiring a PRIORITIZE frame and a HEADERS frame together seems a waste of
>> resources on the link most likely to be the bottleneck.
>>
>> Worse, to get proper behavior out of the server, you'd have to set the
>> priority before sending the resource. Assuming that the PRIORITIZE frame
>> sets a per-stream priority, this is not great, as it requires the server to
>> keep additional state about a stream that hasn't yet arrived. If one sets
>> the priority on stream zero, we could argue that this is setting a default
>> priority for all streams (though that'd be new), which solves this problem,
>> but only over a TCP channel-- mapping to SCTP would again become
>> problematic and rac-y.
>>
>>
>> -=R
>>
>>
>> On Thu, Feb 21, 2013 at 4:31 PM, Martin Thomson <martin.thomson@gmail.com
>> > wrote:
>>
>>> :)
>>>
>>> SYN_STREAM would be next on the list of targets.  Removing that would
>>> require a PRIORITIZE frame and (maybe) a setting to establish a
>>> default stream priority.  The downside is that it would add 4 bytes to
>>> streams where a non-default priority was desired.  Saving 4 bytes on
>>> the default priority might not be a good enough trade-off.
>>>
>>> For my use cases, I don't care about prioritization for most requests,
>>> so that would be a good trade-off.  I'm sure that browsers are more
>>> likely to have a highly variable priority for resources, so it might
>>> be a bad trade-off.  That is, if you cared more about the bits than
>>> the ability to remove another whole frame type.
>>>
>>> On 21 February 2013 16:09, Roberto Peon <grmocg@gmail.com> wrote:
>>> > Indeed, on re-reading the first message, that is what you're proposing.
>>> >
>>> > Seems reasonable to me.
>>> > -=R
>>> >
>>> >
>>> > On Thu, Feb 21, 2013 at 4:07 PM, Roberto Peon <grmocg@gmail.com>
>>> wrote:
>>> >>
>>> >>
>>> >>> > SYN_REPLY doesn't have one, because it doesn't need to declare
>>> >>> > priority--
>>> >>> > the SYN_STREAM already did that, and it is almost always a waste to
>>> >>> > include
>>> >>> > a priority field in SYN_REPLY.
>>> >>>
>>> >>> Agree.  So what does SYN_REPLY actually do then?
>>> >>>
>>> >> It contains a HEADERS block and little else. If you're arguing to
>>> elide
>>> >> SYN_REPLY given HEADERS, then sure, I can see that-- the frame fields
>>> are
>>> >> the same now that we've removed the 'in-reply-to' field.
>>> >>
>>> >> -=R
>>> >
>>> >
>>>
>>
>>
>