Re: BLOCKED frame specification

Bleh.
We have address space in the frame opcodes, lets use that instead of adding
new semantics to things which are unstructured.
The only bit of information that is needed is when the remote end is not
blocked (confirming that it was blocked intentionally/whatever seems like a
waste). That is enough for tuning and debugging.
-=R


On Wed, Apr 16, 2014 at 3:00 AM, David Krauss <potswa@gmail.com> wrote:

> What about working within the PING frame, and making a gentleman’s
> agreement? It’s a conforming extension anyway:
>
> 1. If a stream seems to be blocked, send a PING with the first 4 bytes
> being the stream ID and next 4 bytes indicating some CHECK_BLOCKED opcode
> constant.
>
> 2. If the stream is indeed blocked, the server sends a PING with the
> stream ID, a CONFIRM_BLOCKED opcode, and the ACK bit already set.
>
> 3. In any case, if the connection is OK (which is likely in question,
> too), the server sends a matching reply PING. If this is received before
> any CONFIRM_BLOCKED, the query returns not-blocked.
>
> An additional CONFIRM_NONBLOCKED opcode would allow distinguishing a
> server without the extension from a non-blocked stream, although I imagine
> implementations would be susceptible to false NONBLOCKED results.
>
> For what it’s worth, I don’t see what’s wrong with being more specific
> about PING payloads. If it’s too much to standardize this, perhaps make
> some kind of registry as there is for methods.
>
>
> On 2014–04–16, at 9:06 AM, 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.
>
>