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

Re: BLOCKED frame specification

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 8 Apr 2014 09:59:11 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <491CAADB-2C19-4FBE-9C68-42059C08DA58@mnot.net>
To: Hasan Khalil <mian.hasan.khalil@gmail.com>
Thanks, Hasan.

What do people think?

My inclination at this point is to include this in the implementation draft, but mark it AT RISK -- i.e., we might pull it out before finalising the spec, based upon whether it turns out to be useful in interop.


On 8 Apr 2014, at 7:43 am, Hasan Khalil <mian.hasan.khalil@gmail.com> wrote:

> Here's at least a starting point. Comments welcome.
> The BLOCKED frame (type=0xPLACEHOLDER) conveys flow control and data availability status useful in tuning and debugging flow control.
> The BLOCKED frame contains no payload and does not define any flags. Semantically the BLOCKED frame is used to indicate to a remote endpoint that data subject to flow control was available to be sent, and that the underlying transport was ready to send said data, but was prohibited from sending said data due to either stream-level or connection-level flow control windows being nonpositive. The specific flow control window prohibiting the sending of said data is indicated in the stream id of the BLOCKED frame. In the stream-level flow control blockage case, the frame's stream identifier indicates the affected stream; otherwise the value "0" indicates connection-level flow control blockage.
> Endpoints MUST NOT send a successive BLOCKED frame on a given stream id (including "0") unless the associated flow control window became positive since the last time that a BLOCKED frame for that flow control window was sent. This can happen only as a result of receiving a WINDOW_UPDATE frame or appropriate SETTINGS frame increasing said flow control window. (TODO: Add reference to appropriate sections of flow control spec?) (TODO: Add GOAWAY-ENHANCE_YOUR_CALM usage here as appropriate behavior in this case?)
> BLOCKED can be sent by a peer that has sent a frame bearing the END_STREAM flag. This means that a receiver could receive a BLOCKED frame on a "half closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an error, see Section 5.1.

Mark Nottingham   http://www.mnot.net/
Received on Monday, 7 April 2014 23:59:39 UTC

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