Re: BLOCKED frame specification

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
>