- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 26 Feb 2013 12:00:41 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Roberto Peon <grmocg@gmail.com>, William Chan (ιζΊζ) <willchan@chromium.org>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
Opening as: https://github.com/http2/http2-spec/issues/44 ... and marking as ready for the editors to have a kick at it. Regards, On 21/02/2013, at 10:00 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > On 20 February 2013 14:52, Roberto Peon <grmocg@gmail.com> wrote: >> I'm afraid of simply sending a large window size, because I suspect that >> simple implementations will mess it up for objects > 31 bits in size. > > Yes. Absolutely. > >> If we don't have a SETTINGS thing, then we're requiring flow control for the >> first RT for any stream. > > Yes, that's the implication. Though a client is always able to > disable flow control without consequence, because it speaks first, > before the server sends anything. It's only servers that need to > worry about having it on briefly. The consequences are minimal - they > just don't receive as many packets as they possibly could - but then > that is always true for two reasons: TCP INIT CWD and the time it > takes to send the WINDOW_UPDATE. > >> I like the flag solely because it is difficult to do by accident, unlike >> using zero (which is technically fine otherwise) > > I don't believe in accidents, but I see your point. > >> The other thing to consider is when, if ever, one can transition from >> flow-control disabled to requiring its use again. >> Even if we don't allow this, it will require text explaining it. > > I thought about this. The obvious choice is to start again from zero > when a WINDOW_UPDATE comes in. The problem is knowing (at the > receiver end) when counting started. Once you stop counting, that's > the real difficulty. I believe that once it's off, flow control will > need to stay off. -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 26 February 2013 01:03:27 UTC