Subject: SYN_REPLY

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 15:04:06 -0800

I'm looking at the HTTP/2.0 streaming layer and it's not clear to me
what value SYN_REPLY adds.

SYN_STREAM establishes priority for a stream (and that's all!).
SYN_REPLY doesn't have the power of refusal, that's what RST_STREAM is
for.

There's no need to have a special declaration that a stream is
starting, the first message on a stream should be a clear enough
indication of that.

It does carry headers, but HEADERS does a bang-up job of that.  In all
other respects, SYN_REPLY and HEADERS are identical.

Do we even need the SYN_REPLY frame type?

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 15:11:26 -0800

The SYN_REPLY doesn't need a priority field.
-=R

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 15:11:55 -0800

or rather, it doesn't have one, but the former follows from this :)
-=R

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 15:34:01 -0800

Yes, SYN_STREAM has the priority.

The point is that if you just start using streams (as you do), then a
stream "start" message is only necessary if there are once-only things
to say about the stream.  By that measure, SYN_REPLY has no value.

You wanted to reprioritize, so maybe you could just define PRIORITIZE.
 A stream would optionally start with PRIORITIZE and then HEADERS.
That would be enough.  The response could just use HEADERS.

(On an tangentially related point, I don't see how we could have a
single header with a value that spans two frames in the current
scheme, perhaps you can keep this in mind when you propose an edit for
delta-coding.)

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 15:54:02 -0800

I mean that SYN_STREAM has a priority, which is mandatory because without
it the browser won't trust the server-side to do the right thing.
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.

I intend to consume a flag value which indicates that the semantic-frame is
longer than the current frame. The delta code already does this. I think I
stuck that in the SPDY/4 stuff (so it could be pulled from there, unless
I'm misremembering).
-=R

On Thu, Feb 21, 2013 at 3:34 PM, Martin Thomson <[email-masked]>wrote:

> >> On Thu, Feb 21, 2013 at 3:04 PM, Martin Thomson <
> [email-masked]>
> >> wrote:
> >>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 16:02:04 -0800

On 21 February 2013 15:54, Roberto Peon <[email-masked]> wrote:
> I mean that SYN_STREAM has a priority, which is mandatory because without it
> the browser won't trust the server-side to do the right thing.

Yes.

> a priority field in SYN_REPLY.

Agree.  So what does SYN_REPLY actually do then?

> stuck that in the SPDY/4 stuff (so it could be pulled from there, unless I'm
> misremembering).

A "To be continued..." flag sounds about right.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 16:07:14 -0800

> 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

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 16:09:28 -0800

Indeed, on re-reading the first message, that is what you're proposing.

Seems reasonable to me.
-=R

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 16:31:33 -0800

:)

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.

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 22 Feb 2013 13:31:37 +1300

On 22/02/2013 12:54 p.m., Roberto Peon wrote:
> I mean that SYN_STREAM has a priority, which is mandatory because 
> without it the browser won't trust the server-side to do the right thing.
> 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.

When we start rationalizing server-push semantics so multiple replies 
can be sent for one request. Most of the replies will need to be 
assigned some lower priority than the requested reply - hopefully all 
within the one stream. We will have to define a new response frame 
entirely to replace reply. Why not just do it now and have initial 
implementations compatible with those later ones?

Amos

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 16:38:49 -0800

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 <[email-masked]>wrote:

> >>> > priority--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 16:39:18 -0800

s/resource/request.
*sigh*
-=R

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 16:39:55 -0800

On 21 February 2013 16:31, Amos Jeffries <[email-masked]> wrote:
> When we start rationalizing server-push semantics so multiple replies can be
> sent for one request. Most of the replies will need to be assigned some
> lower priority than the requested reply - hopefully all within the one
> stream. We will have to define a new response frame entirely to replace
> reply. Why not just do it now and have initial implementations compatible
> with those later ones?

I don't get where you are going with this.  It's already possible to
send multiple replies for a single request.  Each request gets its own
stream.

The server actually sends a SYN_STREAM for each extra "reply" (pushed
resource).  These streams are unidirectional.  The client doesn't get
to do anything to these streams, except reject them.  With push
promises, there is a push promise, followed by a later SYN_STREAM.

Currently, the server chooses priority for pushed streams, but our
Google friends (sorry I can't remember who specifically raised this,
probably Will) are interested in reprioritising streams, which would
allow a client to have a say about request priority.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 21 Feb 2013 16:50:40 -0800

Multiple people from the Google contingent (not just Will) are interested
in reprioritization and specifically allowing a 'client' (most likely a
proxy) to reprioritize pushed data.

-=R

On Thu, Feb 21, 2013 at 4:39 PM, Martin Thomson <[email-masked]>wrote:

> can be

---

From: Yoav Nir <[email-masked]>
Date: Fri, 22 Feb 2013 09:44:17 +0000

On Feb 22, 2013, at 2:38 AM, Roberto Peon <[email-masked]> 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.

Hi Roberto

should resources have the same priority throughout their transmission?  Some resources, such as images and maybe music/video, we'd like to get the start of early on.

All image formats that I know of have the image dimensions at the beginning. So if you have a tag like <img src="…"> the browser has no idea how much room to leave for the image. So with some sites you get some initial rendering, and then the page elements begin moving all over the place, adjusting to the actual size of the image, even before most of the image is displayed. I think it should be our goal to minimize this "moving around" time. OTOH we don't want images to have the highest priority in general.

Perhaps it would help to have the browser specify an "initial boost" for the resource, so that the first X bytes (X determined by the server) are sent with very high priority, afterwards dropping to their regular priority as specified by the client. This can't be done with a subsequent PRIORITY, because X should be small relative to the amount of data the server manages to send within a round-trip time.

What do you think?

Yoav

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:05:51 -0800

Many will, but some should likely be re-prioritized. This is what we've
been arguing, and for various reasons, some of which are:
  don't want a video or similar stream monopolizing all bandwidth,
especially when not looking at the tab
  want to ensure that the active tab gets the most bandwidth when loading a
bunch of tabs, e.g. at startup when restoring tabs, or when opening up a
large number of tabs
  want to ensure that resources in the active viewport are given bandwidth
(a further refinement of the idea above)
  want to ensure relative fairness from a proxy, but don't want to throttle
the server unnecessarily

One of the earliest things we played around with was what you're
suggesting-- sending the first X bytes of images, and then continuing,
ostensibly so the layout engine could figure out layout more quickly,
causing fewer reflows, etc. but it didn't yield significant gains at the
time.
That was some time ago, so another experiment along those lines is
interesting.
... but, the interesting thing is that this is 100% within the bounds of
implementation leeway. If a particular implementation finds that this is a
good optimization, then I'm sure we'll see it happen. Ditto for other
similar refinements such as sending progressive images in more intelligent
ways so that the page is useful more quickly.
I don't think it is especially interesting to have the browser specify
this. Much of the time it won't know what the resource is, etc, and so the
hint is likely going to instruct the server to do something worse than what
it would do with the knowledge it has about the resources...
-=R

On Fri, Feb 22, 2013 at 1:44 AM, Yoav Nir <[email-masked]> wrote:

> encountered.
> should resources have the same priority throughout their transmission?
>  Some resources, such as images and maybe music/video, we'd like to get the
> start of early on.
>
> All image formats that I know of have the image dimensions at the
> beginning. So if you have a tag like <img src="…"> the browser has no idea
> how much room to leave for the image. So with some sites you get some
> initial rendering, and then the page elements begin moving all over the
> place, adjusting to the actual size of the image, even before most of the
> image is displayed. I think it should be our goal to minimize this "moving
> around" time. OTOH we don't want images to have the highest priority in
> general.
>
> Perhaps it would help to have the browser specify an "initial boost" for
> the resource, so that the first X bytes (X determined by the server) are
> sent with very high priority, afterwards dropping to their regular priority
> as specified by the client. This can't be done with a subsequent PRIORITY,
> because X should be small relative to the amount of data the server manages
> to send within a round-trip time.
>
> What do you think?
>
> Yoav
>
>

---

From: Patrick McManus <[email-masked]>
Date: Sat, 23 Feb 2013 15:47:38 -0500

> allow a client to have a say about request priority.

yes - I need that too.

---

From: Patrick McManus <[email-masked]>
Date: Sat, 23 Feb 2013 15:50:58 -0500

> All image formats that I know of have the image dimensions at the beginning. So if you have a tag like <img src="…"> the browser has no idea how much room to leave for the image. So with some sites…

yes, this is something I want to be able to experiment with..
especially as some image formats get larger to accommodate ever more
impressive displays. Its a good argument for reprioritization I think
as the simplest mechanism.

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 11:13:19 +1100

OK, created as:
  https://github.com/http2/http2-spec/issues/43

and marked for incorporation by editors; if someone wants to keep SYN_REPLY, pleas say so now.

On 22/02/2013, at 11:09 AM, Roberto Peon <[email-masked]> wrote:

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

--
Mark Nottingham   http://www.mnot.net/

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 25 Feb 2013 20:36:16 -0800

It's kinda nice when reading the spec to have a symmetric
SYN_STREAM&SYN_REPLY. Is there a reason to prefer the HEADERS name over the
SYN_REPLY name? One main use case with HEADERS was for server push, but now
that we're opting to use a PUSH_PROMISE frame rather than a SYN_STREAM as
our "promise", we don't need HEADERS since we'll just send a SYN_STREAM
when we need it.

How important is supporting stuff like chunked extension headers and http
trailers? I guess we need to support it for backwards compatibility reasons
with HTTP/1.X? I guess if we need that, then a HEADERS name might be more
"general", but it is somewhat hurtful for the common case where all the
headers come back in a single reply.

If no one has other comments about this, then don't worry about my concerns
and move forward anyways. I'm more lamenting the assymetry of SYN_STREAM
and HEADERS. I suspect it'll confuse people. Honestly, despite the
"wastefulness" of a frame type, maybe it's better for clarity's sake to
burn a frame type (they're cheap). I think the code cost is cheap too.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 25 Feb 2013 20:36:57 -0800

I spoke up. But my concerns aren't huge. If no one supports me, please move
forward.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 25 Feb 2013 20:39:25 -0800

HEADERS can be used for arbitrary other key-value metadata, in
other-than-HTTP semantic layers so it more general a name than SYN_REPLY.

It is cheap either way, and I don't care either way :)
-=R

On Mon, Feb 25, 2013 at 8:36 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> If no one has other comments about this, then don't worry about my
> concerns and move forward anyways. I'm more lamenting the assymetry of
> SYN_STREAM and HEADERS. I suspect it'll confuse people. Honestly, despite
> the "wastefulness" of a frame type, maybe it's better for clarity's sake to

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 25 Feb 2013 20:42:43 -0800

Fully agreed it's more general. I think that unless we go all the way with
ditching SYN_STREAM too (which I disagree with), then I think it's a net
loss (primarily due to more difficulty in grokking the spec) to save a
frame type value and combine SYN_REPLY and HEADERS into one.

On Mon, Feb 25, 2013 at 8:39 PM, Roberto Peon <[email-masked]> wrote:

> On Mon, Feb 25, 2013 at 8:36 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>>>>> 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
>>>>
>>>
>>>
>>
>

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Feb 2013 20:43:53 -0800

I would say it's likely premature to remove it at this stage but it is
something that ought to be tracked.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 25 Feb 2013 20:50:35 -0800

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 <[email-masked]> wrote:

>> On Thu, Feb 21, 2013 at 4:31 PM, Martin Thomson <[email-masked]
>> > wrote:
>>
>>> :)
>>>
>>> elide

---

From: James M Snell <[email-masked]>
Date: Mon, 25 Feb 2013 20:51:45 -0800

"Combining SYN_REPLY and HEADERS" isn't quite the right terminology
here but I believe there is some optimization that we can get by
eliminating SYN_REPLY and using SYN_STREAM to signal responses. If the
outbound SYN_STREAM has the same opaque-id as the inbound SYN_STREAM,
then it's a reply. That ought to be easy enough to coordinate and
gives us good consistency with SYN_STREAMS for pushes. That gives us
the potential option of allowing servers to prioritize response
traffic.

For right now, however, I'd say it's likely best to leave SYN_REPLY as
it is and do some experimentation to figure out if this optimization
really does make sense. We can pull SYN_REPLY out in the next
iteration.

On Mon, Feb 25, 2013 at 8:42 PM, William Chan (陈智昌)
<[email-masked]> wrote:
> loss (primarily due to more difficulty in grokking the spec) to save a frame
> type value and combine SYN_REPLY and HEADERS into one.
>
>
>> <[email-masked]> wrote:
>>>
>>> our "promise", we don't need HEADERS since we'll just send a SYN_STREAM when
>>> we need it.
>>>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Feb 2013 15:35:29 -0800

Interesting that you think that it's a optimization that needs
experimentation.  There's no need to perform experiments to see if
removing a code point has had the desired effect.  When the code point
isn't there, everything is better.

Will seems to think that some explicit indication that this is a
stream start is nice.  I disagree*, but wont fight for this.  I see
the current design as being confused in the way that it communicates
with respect to streams starting and stopping.  This is exacerbated by
the existence of three different header-carrying frame types.

I would prefer to see streams begin when frames are sent on them.
This is how the protocol really works, but SYN_* gives the false
impression that streams have a negotiated open sequence.

--Martin

*Consistency should always be the last argument for doing anything.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Feb 2013 16:15:34 -0800

> type value and combine SYN_REPLY and HEADERS into one.

I'm interested in what you feel SYN_STREAM provides that you can't get
with HEADERS.

I don't care either way about whether the priority is in the message
or not.  So, in the interests of saving those few bytes, that's a
feature that could be retained (or even moved to HEADERS).

The only other thing is the UNIDIRECTIONAL flag.  This flag is
currently redundant: all streams sent by the client are bidirectional,
and all streams from the server are unidirectional without exception.

As I said in another mail, I'm not sure that SYN_STREAM/SYN_REPLY
actually help with understanding the spec.  On the contrary, I think
that they lead to false impressions about how streams start.  They
imply negotiation, which is far from the case.

---

From: James M Snell <[email-masked]>
Date: Tue, 26 Feb 2013 16:34:26 -0800

What I think needs experimentation is making sure we don't actually
need SYN_REPLY before removing it. I'm all for optimizing where we
can, so long as such optimization isn't premature. I suspect that our
intuitions regarding SYN_REPLY are correct but until we get some
running code that demonstrates that the optimization is effective, I'd
rather hold off and keep things like they are.  (I will say that I
agree with you, I don't think we need SYN_REPLY).

---

From: Martin Thomson <[email-masked]>
Date: Tue, 26 Feb 2013 17:01:28 -0800

I don't believe that this is about intuitions or guessing, or beliefs,
I thought it was about mathematics or formal logic:

informationContent(SYN_REPLY) == informationContent(HEADERS)
positionInStream(SYN_REPLY) != positionInStream(HEADERS)

positionInStream isn't a necessary distinction because the order in
which packets arrive determines that.

Therefore, SYN_REPLY is redundant.

Redundant features are bad.

Therefore, SYN_REPLY should be removed.

Now, I really don't know what an experiment is going to add to this.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 17:19:18 -0800

On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <[email-masked]>wrote:

> frame

I'm not completely clear here on the stated proposal, so I'll just
reclarify my position here. I think that the priority should be
communicated in the same frame which starts the stream, whether that frame
be called SYN_STREAM or HEADERS. I'm not sure if it makes sense to continue
including the priority information for followup headers, that may arrive in
a HEADERS frame. I'm leaning towards saying it does not.

> and all streams from the server are unidirectional without exception.

I think in the normal HTTP use case, yes. But when you view HTTP/2 as a
transport layer for other protocols, then I think it might be reasonable to
have the server initiate a bidirectional stream. Currently there's no
binding for that in the web platform, but you could imagine it (register an
event handler for server initiated streams, rather than relying on hanging
GETs / client initiated WebSockets). I don't feel strongly here due to not
having a concrete use case.

> imply negotiation, which is far from the case.

Intriguing. I did not read the read the earlier email and that was my bad.
I think I have a bias because it's always been called SYN_STREAM and
SYN_REPLY and that's how I conceptualize it. I'm willing to say that my
conceptions on the naming might be very biased and maybe should be
discounted.

In summary, here's my current position:
* the first frame for a stream should include its priority (to be clear, I
don't view the PUSH_PROMISE as belonging to the promised new stream, but to
the associated stream)
* it feels weird to me for subsequent frames on the stream that include the
header name/value block to also include the priority. i don't like the
tight coupling of that.
* i feel less strongly about the naming of SYN_STREAM+SYN_REPLY vs HEADERS,
after what Martin wrote. i fully admit my mental bias here.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 27 Feb 2013 16:37:54 +1300

On 27/02/2013 2:19 p.m., William Chan (陈智昌) wrote:
> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     On 25 February 2013 20:42, William Chan (陈智昌)
>     <[email-masked] <mailto:[email-masked]>> wrote:
> communicated in the same frame which starts the stream, whether that 
> frame be called SYN_STREAM or HEADERS. I'm not sure if it makes sense 
> to continue including the priority information for followup headers, 
> that may arrive in a HEADERS frame. I'm leaning towards saying it does 
> not.
>
>
> I think in the normal HTTP use case, yes. But when you view HTTP/2 as 
> a transport layer for other protocols, then I think it might be 
> reasonable to have the server initiate a bidirectional stream. 
> Currently there's no binding for that in the web platform, but you 
> could imagine it (register an event handler for server initiated 
> streams, rather than relying on hanging GETs / client initiated 
> WebSockets). I don't feel strongly here due to not having a concrete 
> use case.
>
>
> Intriguing. I did not read the read the earlier email and that was my 
> bad. I think I have a bias because it's always been called SYN_STREAM 
> and SYN_REPLY and that's how I conceptualize it. I'm willing to say 
> that my conceptions on the naming might be very biased and maybe 
> should be discounted.
>
> * the first frame for a stream should include its priority (to be 
> clear, I don't view the PUSH_PROMISE as belonging to the promised new 
> stream, but to the associated stream)
> * it feels weird to me for subsequent frames on the stream that 
> include the header name/value block to also include the priority. i 
> don't like the tight coupling of that.

I do like it and from earlier readings I'm not alone in that. Priority 
needs to be adaptable within the duration of the stream _in total_. 
Ignoring the idea one end adjusting priority dynamically.... client can 
still name its priority based on objects importance for whatever its 
user is doing, and server claim a higher/lower relative priority based 
on its own knowledge of the web site/service resource. There is no 
contradictions there and adjusting the priority preference after input 
from both ends should not be allowed to affect the traffic flow in any 
major way - at worst some resources may get slower response time because 
they initially claimed lower priority and raising it was rejected by the 
assigning algorithm.

> * i feel less strongly about the naming of SYN_STREAM+SYN_REPLY vs 
> HEADERS, after what Martin wrote. i fully admit my mental bias here.

When there are two features largely duplicating the same things bias is 
expected. :-)

Amos

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 19:49:43 -0800

On Tue, Feb 26, 2013 at 7:37 PM, Amos Jeffries <[email-masked]> wrote:

>> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <[email-masked]<mailto:
>> martin.thomson@gmail.**com <[email-masked]>>> wrote:
>>
>>     <[email-masked] <mailto:[email-masked]>**> wrote:
>> bad. I think I have a bias because it's always been called SYN_STREAM and
>> * the first frame for a stream should include its priority (to be clear,
>> I don't view the PUSH_PROMISE as belonging to the promised new stream, but
>> to the associated stream)
>> * it feels weird to me for subsequent frames on the stream that include
>> the header name/value block to also include the priority. i don't like the
>> tight coupling of that.
>>
>
> still name its priority based on objects importance for whatever its user
> is doing, and server claim a higher/lower relative priority based on its
> own knowledge of the web site/service resource. There is no contradictions
> there and adjusting the priority preference after input from both ends
> should not be allowed to affect the traffic flow in any major way - at
> worst some resources may get slower response time because they initially
> claimed lower priority and raising it was rejected by the assigning
> algorithm.

Just to be clear, I am very open to reprioritization, and in fact do want
to experiment with it in HTTP/2. I'm just saying that I feel that it's
weird to couple it to whatever frame carries the header name/value block.
I'm trying to work through my head the implications here. I think it means
that *if* I want to send a follow up HEADERS frame, I'd have to remember
the priority of the stream, whereas today I calculate it once based off the
resource type and forget it. Not a huge deal, bookkeeping's easy and the
extra state is cheap. But it seems nice not to require it.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 26 Feb 2013 19:53:24 -0800

I'm about as clear as mud about what we're actually talking about now :)

-=R

On Tue, Feb 26, 2013 at 7:49 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> On Tue, Feb 26, 2013 at 7:37 PM, Amos Jeffries <[email-masked]>wrote:
>
>>> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <
>>> [email-masked] <mailto:martin.thomson@gmail.**com<[email-masked]>>>
>>> wrote:
>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 20:03:25 -0800

Probably my fault :) My understanding of the thread in respect to this
particular point
* Martin is proposing combining SYN_STREAM+SYN_REPLY+HEADERS into a single
HEADERS frame.
  - single HEADERS frame might contain priority
  - otherwise, we need a PRIORITIZE frame
* I want the initial stream frame (whether it be HEADERS or SYN_STREAM) to
contain a priority.
* Furthermore, I find it weird for subsequent frames carrying the header
name/value block to *also* carry a priority. This is what I objected to as
"tight coupling" of priority with headers name/value blocks in all
HEADERS-esque frames.
  - This somewhat implies we should use separate frames.
* I believe Amos read my statement as arguing against stream
reprioritization over its lifetime. As I've previously said on this mailing
list, I am in favor of experimenting with stream reprioritization.

On Tue, Feb 26, 2013 at 7:53 PM, Roberto Peon <[email-masked]> wrote:

> On Tue, Feb 26, 2013 at 7:49 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 26 Feb 2013 20:16:44 -0800

Ah. That explains my confusion :)

My understanding was we would replace any reference to SYN_REPLY with
HEADERS (the frames are exactly the same except for the opcodes), leave
SYN_STREAM alone, and leave HEADERS alone.
That I'd support.

Taking the priority out of SYN_STREAM would only bloat things on the wire,
since the client will always want to state priority for a new stream. I
don't support removing priority from SYN_STREAM.

-=R

On Tue, Feb 26, 2013 at 8:03 PM, William Chan (陈智昌)
<[email-masked]>wrote:

>> On Tue, Feb 26, 2013 at 7:49 PM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>
>>>>> a transport layer for other protocols, then I think it might be reasonable
>>>>> to have the server initiate a bidirectional stream. Currently there's no
>>>>> include the header name/value block to also include the priority. i don't
>>>>> like the tight coupling of that.
>>>>>
>>>>
>>> Just to be clear, I am very open to reprioritization, and in fact do
>>> want to experiment with it in HTTP/2. I'm just saying that I feel that it's

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Feb 2013 15:20:53 +1100

That was my understanding too. 

On 27/02/2013, at 3:16 PM, Roberto Peon <[email-masked]> wrote:

> My understanding was we would replace any reference to SYN_REPLY with HEADERS (the frames are exactly the same except for the opcodes), leave SYN_STREAM alone, and leave HEADERS alone.
> That I'd support.
> 
> Taking the priority out of SYN_STREAM would only bloat things on the wire, since the client will always want to state priority for a new stream. I don't support removing priority from SYN_STREAM.
> 
> -=R
> 
> 
> On Tue, Feb 26, 2013 at 8:03 PM, William Chan (陈智昌) <[email-masked]> wrote:
> Probably my fault :) My understanding of the thread in respect to this particular point
> * Martin is proposing combining SYN_STREAM+SYN_REPLY+HEADERS into a single HEADERS frame.
> * I want the initial stream frame (whether it be HEADERS or SYN_STREAM) to contain a priority.
> * Furthermore, I find it weird for subsequent frames carrying the header name/value block to *also* carry a priority. This is what I objected to as "tight coupling" of priority with headers name/value blocks in all HEADERS-esque frames.
> * I believe Amos read my statement as arguing against stream reprioritization over its lifetime. As I've previously said on this mailing list, I am in favor of experimenting with stream reprioritization.
> 
> 
> On Tue, Feb 26, 2013 at 7:49 PM, William Chan (陈智昌) <[email-masked]> wrote:
> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I'm not completely clear here on the stated proposal, so I'll just reclarify my position here. I think that the priority should be communicated in the same frame which starts the stream, whether that frame be called SYN_STREAM or HEADERS. I'm not sure if it makes sense to continue including the priority information for followup headers, that may arrive in a HEADERS frame. I'm leaning towards saying it does not.
> 
> 
> I think in the normal HTTP use case, yes. But when you view HTTP/2 as a transport layer for other protocols, then I think it might be reasonable to have the server initiate a bidirectional stream. Currently there's no binding for that in the web platform, but you could imagine it (register an event handler for server initiated streams, rather than relying on hanging GETs / client initiated WebSockets). I don't feel strongly here due to not having a concrete use case.
> 
> 
> Intriguing. I did not read the read the earlier email and that was my bad. I think I have a bias because it's always been called SYN_STREAM and SYN_REPLY and that's how I conceptualize it. I'm willing to say that my conceptions on the naming might be very biased and maybe should be discounted.
> 
> * the first frame for a stream should include its priority (to be clear, I don't view the PUSH_PROMISE as belonging to the promised new stream, but to the associated stream)
> * it feels weird to me for subsequent frames on the stream that include the header name/value block to also include the priority. i don't like the tight coupling of that.
> 
> I do like it and from earlier readings I'm not alone in that. Priority needs to be adaptable within the duration of the stream _in total_. Ignoring the idea one end adjusting priority dynamically.... client can still name its priority based on objects importance for whatever its user is doing, and server claim a higher/lower relative priority based on its own knowledge of the web site/service resource. There is no contradictions there and adjusting the priority preference after input from both ends should not be allowed to affect the traffic flow in any major way - at worst some resources may get slower response time because they initially claimed lower priority and raising it was rejected by the assigning algorithm.
> 
> Just to be clear, I am very open to reprioritization, and in fact do want to experiment with it in HTTP/2. I'm just saying that I feel that it's weird to couple it to whatever frame carries the header name/value block. I'm trying to work through my head the implications here. I think it means that *if* I want to send a follow up HEADERS frame, I'd have to remember the priority of the stream, whereas today I calculate it once based off the resource type and forget it. Not a huge deal, bookkeeping's easy and the extra state is cheap. But it seems nice not to require it.
>  
> 
> 
> * i feel less strongly about the naming of SYN_STREAM+SYN_REPLY vs HEADERS, after what Martin wrote. i fully admit my mental bias here.
> 
> When there are two features largely duplicating the same things bias is expected. :-)
> 
> Amos
> 
> 
> 
> 
>

---

From: James M Snell <[email-masked]>
Date: Tue, 26 Feb 2013 20:28:22 -0800

> SYN_STREAM alone, and leave HEADERS alone.

If we're certain that all we need in the initial response frame is a
bag of headers, then +1.

> don't support removing priority from SYN_STREAM.

+1

- James

>>>>>> reclarify my position here. I think that the priority should be communicated
>>>>>> in the same frame which starts the stream, whether that frame be called
>>>>>> SYN_STREAM or HEADERS. I'm not sure if it makes sense to continue including
>>>>>> the priority information for followup headers, that may arrive in a HEADERS
>>>>>> frame. I'm leaning towards saying it does not.
>>>>>>
>>>>>>
>>>>> needs to be adaptable within the duration of the stream _in total_. Ignoring
>>>>> the idea one end adjusting priority dynamically.... client can still name
>>>>> its priority based on objects importance for whatever its user is doing, and
>>>>> server claim a higher/lower relative priority based on its own knowledge of
>>>>> the web site/service resource. There is no contradictions there and
>>>>> adjusting the priority preference after input from both ends should not be
>>>>> allowed to affect the traffic flow in any major way - at worst some
>>>>> resources may get slower response time because they initially claimed lower
>>>>> priority and raising it was rejected by the assigning algorithm.
>>>>
>>>>
>>>> that *if* I want to send a follow up HEADERS frame, I'd have to remember the
>>>> priority of the stream, whereas today I calculate it once based off the

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 20:46:34 -0800

Great! I'm more or less OK with this (despite my minor reservations about
lack of symmetry with SYN_STREAM and response in HEADERS).

Just so no one thinks I'm too crazy, I was mostly replying to this email
earlier:
http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0944.html. I
was unclear if we had achieved consensus on that.

On Tue, Feb 26, 2013 at 8:28 PM, James M Snell <[email-masked]> wrote:

> > On Tue, Feb 26, 2013 at 8:03 PM, William Chan (陈智昌) <
> [email-masked]>
> > wrote:
> >>
> >>>>>>     > loss (primarily due to more difficulty in grokking the spec)
> to
> >>>>>>     save a frame
> >>>>>>     I'm interested in what you feel SYN_STREAM provides that you
> can't
> >>>>>> get
> >>>>>>     with HEADERS.
> >>>>>>
> communicated
> reasonable
> Ignoring

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Feb 2013 16:00:40 +1100

OK, let's do it then.

Regards,

On 27/02/2013, at 3:46 PM, William Chan (陈智昌) <[email-masked]> wrote:

> Great! I'm more or less OK with this (despite my minor reservations about lack of symmetry with SYN_STREAM and response in HEADERS).
> 
> Just so no one thinks I'm too crazy, I was mostly replying to this email earlier: http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0944.html. I was unclear if we had achieved consensus on that.
> 
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 10:20:55 -0800

> don't support removing priority from SYN_STREAM.

What if HEADERS contained priority?  Is your objection to removing
priority from SYN_STREAM, or removing priority from the first frame in
the stream.

Here's a more concrete proposal, albeit slightly radical.

Remove SYN_STREAM and SYN_REPLY.
Have stream-level flags that appear in ALL messages.
 1. last frame in stream (the existing FIN bit)
 2. stream priority (a new one)
The 'stream priority' flag indicates that the first 4 bytes of the
frame payload includes a priority.  This should (or SHOULD) be set on
the first frame of any stream.

Then a typical stream looks like:
 - a HEADERS frame with the 'stream priority' flag set, plus a priority
 - a bunch of data frames
 - maybe some other frames

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 10:45:23 -0800

The we're wasting bytes on responses. Bleh. Worse, now we can't simply
examine the length field to figure out what to do. Double-eww.
In any case, spending a bit in the flags, is far more costly than spending
the fractional bit out of the opcode space, which is what is done today!

Something I could go with, given the previous change would be to also
change the name of SYN_STREAM to HEADERS_WITH_PRIO
and leave HEADERS as it is.

How does that sound?

-=R

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 10:46:37 -0800

That should have read:
Then we're either wasting bytes on responses or we  can't simply examine..

Blarg! Terrible typing!

On Wed, Feb 27, 2013 at 10:45 AM, Roberto Peon <[email-masked]> wrote:

> On Wed, Feb 27, 2013 at 10:20 AM, Martin Thomson <[email-masked]
> > wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 11:07:27 -0800

Opcode or flags, it matters not.  It depends on where you want to
spend your bit (or part thereof).

On 27 February 2013 10:45, Roberto Peon <[email-masked]> wrote:
> Something I could go with, given the previous change would be to also change
> the name of SYN_STREAM to HEADERS_WITH_PRIO
> On Wed, Feb 27, 2013 at 10:20 AM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 11:16:30 -0800

Shall I take that as an agreement? :)
-=R

On Wed, Feb 27, 2013 at 11:07 AM, Martin Thomson
<[email-masked]>wrote:

> change

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 11:17:52 -0800

If you like.  This hasn't addressed the unidirectional piece though.

On 27 February 2013 11:16, Roberto Peon <[email-masked]> wrote:
> On Wed, Feb 27, 2013 at 11:07 AM, Martin Thomson <[email-masked]>
> wrote:
>>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Feb 2013 11:18:53 -0800

I think that is more related to the discussion in the other thread, and
probably should be discussed there, no?

On Wed, Feb 27, 2013 at 11:17 AM, Martin Thomson
<[email-masked]>wrote:

> >> >> > Taking the priority out of SYN_STREAM would only bloat things on
> the
> >> >> > wire,
> >> >> > since the client will always want to state priority for a new
> stream.
> >> >> > I

---

From: Martin Thomson <[email-masked]>
Date: Wed, 27 Feb 2013 11:51:26 -0800

OK, here's where I think we're at, in concrete terms:

We have a HEADERS frame.
We have a HEADERS+PRIORITY frame that includes an extra 4 bytes up front.

Either can be sent in all the normal places that you would expect to
see HEADERS, SYN_STREAM or SYN_REPLY.  Most importantly, when a stream
starts.

Pushed streams are unidirectional by virtue of being initiated by the
server, not by explicit indication.  The server does not expect data
frames from the client and MAY discard them.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 27 Feb 2013 11:58:54 -0800

I'm fine with this but there are details that need to be covered in the
spec. When a stream starts, the client MUST use the HEADERS+PRIORITY frame.
Otherwise, we need to spec out what happens when you have some streams with
unspecified priority and some streams with specified priority. I'd rather
just mandate we always include the priority. For clients which don't care
about priority, always pick the same arbitrary value.

PS: I raised a minor point earlier about possibly allowing bidirectional
server initiated streams. I don't feel strongly about it, and if an actual
use case arises, I'm happy to re-raise later.

---

From: Hasan Khalil <[email-masked]>
Date: Wed, 27 Feb 2013 16:12:27 -0500

It sounds like we're roughly back to keeping SYN_STREAM (which is basically HEADERS with a priority) and ditching SYN_REPLY for HEADERS.

I'm on board with this.  

-Hasan

On Wednesday, February 27, 2013 at 2:58 PM, William Chan (陈智昌) wrote:

> I'm fine with this but there are details that need to be covered in the spec. When a stream starts, the client MUST use the HEADERS+PRIORITY frame. Otherwise, we need to spec out what happens when you have some streams with unspecified priority and some streams with specified priority. I'd rather just mandate we always include the priority. For clients which don't care about priority, always pick the same arbitrary value.
>  
> PS: I raised a minor point earlier about possibly allowing bidirectional server initiated streams. I don't feel strongly about it, and if an actual use case arises, I'm happy to re-raise later.  
>  
>  
> On Wed, Feb 27, 2013 at 11:51 AM, Martin Thomson <[email-masked] (mailto:[email-masked])> wrote:

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Feb 2013 16:25:30 +1300

On 28/02/2013 10:12 a.m., Hasan Khalil wrote:
> It sounds like we're roughly back to keeping SYN_STREAM (which is 
> basically HEADERS with a priority) and ditching SYN_REPLY for HEADERS.
>
> I'm on board with this.
>

+1. Same here for those changes.

>> I'm fine with this but there are details that need to be covered in 
>> the spec. When a stream starts, the client MUST use the 
>> HEADERS+PRIORITY frame. Otherwise, we need to spec out what happens 
>> when you have some streams with unspecified priority and some streams 
>> with specified priority. I'd rather just mandate we always include 
>> the priority. For clients which don't care about priority, always 
>> pick the same arbitrary value.
>>
>> PS: I raised a minor point earlier about possibly allowing 
>> bidirectional server initiated streams. I don't feel strongly about 
>> it, and if an actual use case arises, I'm happy to re-raise later.

I disagree on the need for server-initiated streams, Push can work fine 
without turning HTTP semantics into BEEP semantics. But that is a side 
issue I think we will discuss later or elsewhere.

Amos

---

From: Jeff Pinner <[email-masked]>
Date: Wed, 27 Feb 2013 21:57:15 -0800

> spend your bit (or part thereof).

don't we have 256 opcodes but only 8 flags?

---

From: Martin Thomson <[email-masked]>
Date: Thu, 28 Feb 2013 08:15:42 -0800

> don't we have 256 opcodes but only 8 flags?

Clearly, that matters :)  Of course, we do have a much larger space
for frame-type-specific flags when it comes down to it.  Potentially
infinite space.

---

From: RUELLAN Herve <[email-masked]>
Date: Thu, 28 Feb 2013 17:22:04 +0000

Also +1.

And I find that calling SYN_STREAM HEADERS+PRIORITY restore some of the symmetry we lost with SYN_REPLY.

Hervé.

> -----Original Message-----
> From: Amos Jeffries [mailto:[email-masked]]
> Sent: jeudi 28 février 2013 04:26
> To: [email-masked]
> Subject: Re: SYN_REPLY
> 
> without turning HTTP semantics into BEEP semantics. But that is a side issue I
> think we will discuss later or elsewhere.
> 
> Amos