Re: BLOCKED frame specification

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