W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: SYN_REPLY

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 27 Feb 2013 15:20:53 +1100
Cc: William Chan (陈智昌) <willchan@chromium.org>, Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <65B0BF56-EEFF-42B8-BB1F-045FD543C4D0@mnot.net>
To: Roberto Peon <grmocg@gmail.com>
That was my understanding too. 


On 27/02/2013, at 3:16 PM, Roberto Peon <grmocg@gmail.com> wrote:

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

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 27 February 2013 04:21:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 27 February 2013 04:21:28 GMT