Re: SYN_REPLY

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

On Tue, Feb 26, 2013 at 3:35 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> 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.
>
> On 25 February 2013 20:51, James M Snell <jasnell@gmail.com> wrote:
>> "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 (陈智昌)
>> <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.
>>>
>>>
>>> On Mon, Feb 25, 2013 at 8:39 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>>
>>>> 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 (陈智昌)
>>>> <willchan@chromium.org> wrote:
>>>>>
>>>>> 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.
>>>>>
>>>>>
>>>>> On Thu, Feb 21, 2013 at 4:09 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>>>>
>>>>>> Indeed, on re-reading the first message, that is what you're proposing.
>>>>>>
>>>>>> Seems reasonable to me.
>>>>>> -=R
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 21, 2013 at 4:07 PM, Roberto Peon <grmocg@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>> > 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.
>>>>>>>>
>>>>>>>> Agree.  So what does SYN_REPLY actually do then?
>>>>>>>>
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>

Received on Wednesday, 27 February 2013 00:35:14 UTC