Re: SYN_REPLY

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
> >
> >
>