RE: new version of Flow Control Principles

From: Eliot Lear [mailto:lear@cisco.com]
…

That's an excellent draft.  It looks to me like you have largely carried forward the benefit of the research community's experience with TCP, where algorithms evolved over a several decades, but the actual control mechanism has been all but entirely stable.

Gab> thanks, Eliot. I’ve hesitated about raising this analogy as some people have tripped on it and interpreted the text as *being* congestion control, instead of as being a different issue of flow control. At any rate, this text is there to help folks understand the justification for the draft, and is not meant as a textual contribution towards HTTP 2.0. Only section 2 is a texual contribution to HTTP 2.0.

One or two comments:



   5.  HTTP 2.0 should only standardize the format of the window update

       message and its semantics.  In particular, the algorithms used by

       the receiver to decide when to send window update messages, and

       how much to update the window by, are not mandated in the spec.

       The draft should, however, provide some illustrative examples.

The receiver chooses the algorithm through control of the window size.  Therefore, would it make sense to go further in (5) and state that the choice of such algorithms is strictly a matter for the receiver?

Gab> #3, #4 and #5 mention *receiver* quite clearly as being in charge, but if it makes it even clearer, we can something to this effect, yes.

And then on this point:



   NOTE: Whether flow control operates on a per-stream basis, on a per-

   session (per-TCP connection) basis or on both a per-stream and a per-

   session basis is TBD.

Per-session flow control would certainly be required if you're not using TCP or SCTP.  If you are, what is the value of additional flow control at the session level?  Is there any desire for HTTP over UDP (not that I would necessarily object to the notion)?

Gab> I am not wondering too much about HTTP over UDP, as the WG is clearly meant to specify HTTP over TCP initially, so no, that is not the justification for this. Having said that, whatever flow control rules are adopted can apply to different transports. It may become less important to use flow control (or the choice of algorithm may become easier) if the transport layer has different characteristics. For example, I *think* TCP Minion could alleviate the need for flow control, but that is not completely clear yet. The main point is that it does not matter once the basic rules are in place. Your algorithm can be as complex or as simple as needed (even allowing a receiver to turn off flow control altogether if it so wishes). As to the justification for this per-connection or per-session flow control (in addition to per-stream), perhaps Will or Roberto can clarify further, but as I understand it, there is discussion in SPDY/4 to this effect, because even though TCP would back up naturally, it would hit HOL blocking. This tries to avoid it by putting the buffers in user-space, instead of leaving them sitting around in kernel space (which would happen if TCP cannot read due to hitting its limits in buffering).
Thanks, Gabriel

On 12/13/12 5:43 AM, Gabriel Montenegro wrote:
Hi,

We published a new version of the flow control principles:
http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01


The idea is that this is the basic gist of flow control, the basic rules, not a given algorithm. Given a basic set of rules like these, further refined algorithms can be worked on independently and even subsequently to the base specification.

Section 2, the basic set of rules, is being offered to the group for inclusion in the base spec for HTTP 2.0. There seemed to be some support in the room in Atlanta to do so, and hopefully this version will make that easier.

Osama, Jitu, Will, Roberto, Rob, Salvatore and Gabriel