Re: SYN_REPLY

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