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 10:02:22 -0700
Message-ID: <CAP+FsNekOz-GS=us91ZnCfgM3rQv-wmVBkjpgr8ifwzkf3f1aA@mail.gmail.com>
To: David Krauss <potswa@gmail.com>
Cc: Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
Sorry, hit submit by accident :)

Flow control is hop by hop, not end to end, and so all we care about is
detecting the hop-by-hop flow control issues.
Specifically, we care about detecting when the remote side could not send
because its flow control window was zero.

On Wed, Apr 16, 2014 at 9:50 AM, Roberto Peon <grmocg@gmail.com> wrote:

> Flow control is hop by hop, not end to end.
> On Apr 16, 2014 8:39 AM, "David Krauss" <potswa@gmail.com> wrote:
>> On 2014–04–16, at 11:07 PM, Johnny Graettinger <jgraettinger@chromium.org>
>> wrote:
>> I think there's a misunderstanding here. Priorities are about the
>> relative ordering of multiple *ready-to-write* streams. A sender can and
>> certainly should send a dependent stream frame, if that's what's available.
>> I didn’t say anything about priorities. A sender should only send a
>> dependent stream frame if all its dependencies are blocked. Otherwise, the
>> dependent stream is blocked.
>> Can you give an example of when a unidirectional BLOCKED frame would be
>> sent?
>> An empty DATA frame will simply be coalesced (ignored) by the first
>>> intermediary.
>> That's fine. Flow control is also hop-by-hop.
>> It’s not fine because such a debugging/tuning facility stops working if
>> any ISP, load balancer, or firewall employs a proxy.
>> What is it you intend to accomplish? There may be a misunderstanding.
Received on Wednesday, 16 April 2014 17:02:50 UTC

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