- From: David Krauss <potswa@gmail.com>
- Date: Thu, 17 Apr 2014 09:27:14 +0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Johnny Graettinger <jgraettinger@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>
On 2014–04–17, at 1:02 AM, Roberto Peon <grmocg@gmail.com> wrote: > 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. But how do you know that the first hop is the one with blockage? The first rule of debugging is that a problem may be anywhere. If you’re testing interoperability with an external site, you certainly don’t know what’s on their end… Apologies, I was thinking of blockage due to the dependency hierarchy, not flow control. Flow control stalls should frankly never happen. Flow control is supposed to improve reliability, and if it has bugs then the protocol is too complicated. When was the last time TCP flow control stalled an application? Anyway, any blockage-diagnosis facility would probably be more useful if it covered all possible root causes. I’ll try and propose a flow control simplification today, which would outlaw throttling after a stream is in progress but still allow 100 CONTINUE emulation.
Received on Thursday, 17 April 2014 01:27:49 UTC