Re: BLOCKED frame specification

OK, that seems quite reasonable to me. Thanks for the explanation. I can
definitely understand being skeptical of the usefulness of this frame. My
argument is definitely based on a vague fear that is difficult to quantify.
This is again one of those things that I would hope that we would be able
to demonstrate the utility of in practice before having to make a decision
of whether or not it goes into the spec.


On Wed, Apr 16, 2014 at 10:51 AM, Nicholas Hurley <hurley@todesschaf.org>wrote:

> For my part, it's just that I'm not particularly convinced of the
> usefulness of the frame (not to say that I can't be convinced otherwise).
> I'm not opposed to it being specified (assuming we don't hold up the rest
> of the spec... this is very low on the "nice-to-have" list), nor do I think
> it's "bad" (for some value of bad), I'm just not convinced yet.
>
>
> On Tue, Apr 15, 2014 at 6:06 PM, William Chan (陈智昌) <willchan@chromium.org
> > wrote:
>
>> It'd be interesting in hearing why not. Do you think it's net-negative,
>> or is it a question of time/prioritization? And would you oppose
>> specification even if you didn't implement?
>>
>> As Roberto points out, this is more about tuning than just debugging. If
>> things are outright hanging, we can probably debug that. But if performance
>> is just crappy, it is often non-obvious to folks how to debug that. It's my
>> hope that a BLOCKED frame would allow the common webservers to track stats
>> for BLOCKED frames to make it easier to flag these performance tuning
>> issues, rather than having to manually dive into traces, which I don't
>> expect most deployments to do. I may very well be overly-concerned here,
>> but I fear that many will enable HTTP/2 with flow control, and it will
>> "work", but be slow, and people will blame HTTP/2 and not adopt. That would
>> be unfortunate.
>>
>>
>> On Thu, Apr 10, 2014 at 5:13 PM, Nicholas Hurley <hurley@todesschaf.org>wrote:
>>
>>> I am not particularly interested in implementing BLOCKED, whether it
>>> holds up the schedule or not.
>>>
>>>
>>> On Wed, Apr 9, 2014 at 1:38 PM, Rob Trace <Rob.Trace@microsoft.com>wrote:
>>>
>>>>  The BLOCKED frame is not something we are interested in and would
>>>> rather not add another late feature to the spec.  The standard is already
>>>> slipping the schedule and we need to stop adding to the spec.
>>>>
>>>>
>>>>
>>>> Thanks!!
>>>>
>>>>
>>>>
>>>> -Rob
>>>>
>>>>
>>>>
>>>> *From:* Roberto Peon [mailto:grmocg@gmail.com]
>>>> *Sent:* Wednesday, April 9, 2014 2:30 AM
>>>> *To:* Yoav Nir
>>>> *Cc:* David Krauss; HTTP Working Group
>>>> *Subject:* Re: BLOCKED frame specification
>>>>
>>>>
>>>>
>>>> imho, this is useful for tuning, not just debugging.
>>>>
>>>>
>>>>
>>>> And we've found that tuning is annoyingly difficult to get right.
>>>>
>>>>
>>>>
>>>> Obviously I want this, in case that wasn't common knowledge already :)
>>>>
>>>> -=R
>>>>
>>>>
>>>>
>>>> On Wed, Apr 9, 2014 at 2:17 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>>
>>>>
>>>> On Apr 9, 2014, at 12:02 PM, David Krauss <potswa@gmail.com> wrote:
>>>>
>>>> >
>>>> > On 2014–04–09, at 4:59 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
>>>> >
>>>> >> That only tells me if the connection is working, not if the
>>>> resources are not coming because of some server issue (like trouble
>>>> connecting to a back-end database) or because of flow control.
>>>> >
>>>> > Use the implementation-defined payload value. It’s not portable but
>>>> you don’t need portability for debugging.
>>>>
>>>> Looking at section 6.7 of -11 I don’t see any implementation-defined
>>>> payload value, just some opaque data that the receiver should copy into its
>>>> response.
>>>>
>>>> Even if there was, I would be debugging my implementation against some
>>>> other implementation. Not against my own.
>>>>
>>>> Yoav
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Peace,
>>>   -Nick
>>>
>>
>>
>
>
> --
> Peace,
>   -Nick
>