W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: BLOCKED frame specification

From: Roberto Peon <grmocg@gmail.com>
Date: Wed, 16 Apr 2014 03:08:16 -0700
Message-ID: <CAP+FsNeU-FASpbnUjQe37vi58o=AbYtWLqu2U=yqcna4xXJHAw@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: William Chan (陈智昌) <willchan@chromium.org>, Nicholas Hurley <hurley@todesschaf.org>, Rob Trace <Rob.Trace@microsoft.com>, Yoav Nir <ynir.ietf@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
>
>
Received on Wednesday, 16 April 2014 10:08:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:29 UTC