Re: BLOCKED frame specification

On Wed Apr 16 2014 at 6:14:45 PM, William Chan (陈智昌) <willchan@chromium.org>
wrote:

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

...Which is why I'm 100% with Mark on putting this into the next
implementation draft and then getting opinions on its usefulness rather
than discussing in hypotheticals.


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