Re: proposed WINDOW_UPDATE text for session flow control windows

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.

Received on Wednesday, 20 February 2013 23:01:22 UTC