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

BLOCKED frame specification

From: Hasan Khalil <mian.hasan.khalil@gmail.com>
Date: Mon, 07 Apr 2014 21:43:33 +0000
Message-ID: <CAOfQJtf0UC0xzjLSz4vWGsnt4sH9kx8yw8WU_53VpQOeaPC1jg@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Here's at least a starting point. Comments welcome.

6.x BLOCKED

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.
Received on Monday, 7 April 2014 21:44:00 UTC

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