Re: SYN_REPLY

I don't believe that this is about intuitions or guessing, or beliefs,
I thought it was about mathematics or formal logic:

informationContent(SYN_REPLY) == informationContent(HEADERS)
positionInStream(SYN_REPLY) != positionInStream(HEADERS)

positionInStream isn't a necessary distinction because the order in
which packets arrive determines that.

Therefore, SYN_REPLY is redundant.

Redundant features are bad.

Therefore, SYN_REPLY should be removed.

Now, I really don't know what an experiment is going to add to this.

On 26 February 2013 16:34, James M Snell <jasnell@gmail.com> wrote:
> 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 01:01:56 UTC