Re: SYN_REPLY

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

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

Received on Wednesday, 27 February 2013 03:38:23 UTC