Re: SYN_REPLY

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 (陈智昌)
<willchan@chromium.org>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.
>   - 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 <grmocg@gmail.com> wrote:
>
>> 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 (陈智昌) <
>> willchan@chromium.org> wrote:
>>
>>> On Tue, Feb 26, 2013 at 7:37 PM, Amos Jeffries <squid3@treenet.co.nz>wrote:
>>>
>>>> On 27/02/2013 2:19 p.m., William Chan (陈智昌) wrote:
>>>>
>>>>> On Tue, Feb 26, 2013 at 4:15 PM, Martin Thomson <
>>>>> martin.thomson@gmail.com <mailto:martin.thomson@gmail.**com<martin.thomson@gmail.com>>>
>>>>> wrote:
>>>>>
>>>>>     On 25 February 2013 20:42, William Chan (陈智昌)
>>>>>     <willchan@chromium.org <mailto:willchan@chromium.org>**> wrote:
>>>>>     > 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.
>>>>>
>>>>>     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).
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>     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.
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>>     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.
>>>>>
>>>>>
>>>>> 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 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
>>>>
>>>>
>>>
>>
>