Subject: new version of Flow Control Principles

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 13 Dec 2012 04:43:57 +0000

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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 13 Dec 2012 09:37:15 +0100

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

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.

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?

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)? 

Eliot

On 12/13/12 5:43 AM, Gabriel Montenegro wrote:
> 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.
>
>  
>

---

From: Jonathan Ballard <[email-masked]>
Date: Thu, 13 Dec 2012 09:50:19 -0800

After I read it the question that was left was, "where is the debit rule?"
If that question doesn't make sense then maybe "credit" isn't the real
number word for flow control.

On Wednesday, December 12, 2012, Gabriel Montenegro wrote:

>  Hi,****
>
> ** **
>
> We published a new version of the flow control principles:****
>
> ****
> ** **
> 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. ****
>
> ** **
>
> 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****
>
> ** **
>

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 13 Dec 2012 19:16:26 +0000

From: Eliot Lear [mailto:[email-masked]]
…

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:

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:

   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

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 13 Dec 2012 19:19:27 +0000

From: Jonathan Ballard [mailto:[email-masked]]
...

After I read it the question that was left was, "where is the debit rule?" If that question doesn't make sense then maybe "credit" isn't the real number word for flow control.

Gab> Not sure I understand the comment. Could this be related to Eliot's comment that the algorithm is clearly in the hands of the receiver? All the sender has to do to debit towards any available credit is to send as much of that credit as he needs to send. The actual over-the-wire(less) transmission dynamics, of course, are in the hands of the underlying TCP implementation (which would presumably heed congestion control rules, but that is opaque to HTTP 2.0).

Thanks,Gabriel

---

From: Jonathan Ballard <[email-masked]>
Date: Thu, 13 Dec 2012 12:59:41 -0800

For wireless, an algorithm may provide semantic value. On the wire, that
value, or flow, is already present. I would like to say, replace SPDY's
Push/Pull semantic flow with credit and debit accounting. I thought we
already understood balances and currencies.

One sample is Raspberry PI FTP box that runs on solar power. It appears
wasteful not to match power units to credit/debit the flow; when, we can
avoid energy demands spent on extra algorithms that achieve the same. Power
is sent over USB, so that is orthogonal to power over Ethernet. The
blackbox in this sample is the batteries. I can think of many explorations
projects to fine tune such accounting.

My opinion, credit-only numbers lead to more permanent registries as trust
tokens develop. That means the blackbox converts into greybox, which may
not be desired at all. That means more resistance to SPDY.

On Thursday, December 13, 2012, Gabriel Montenegro wrote:

>  ** **
>
> ** **
>
> *From:* Jonathan Ballard [mailto:[email-masked] <javascript:_e({},
> 'cvml', [email-masked]');>]
> *…*****
>
> ** **
>
> Gab> Not sure I understand the comment. Could this be related to Eliot’s
> comment that the algorithm is clearly in the hands of the receiver? All the
> sender has to do to debit towards any available credit is to send as much
> of that credit as he needs to send. The actual over-the-wire(less)
> transmission dynamics, of course, are in the hands of the underlying TCP
> implementation (which would presumably heed congestion control rules, but
> that is opaque to HTTP 2.0).****
>
> ** **
>
> Thanks,Gabriel****
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 13 Dec 2012 16:07:12 -0800

I'm not understanding what you mean by debit. Do you mean revoking some of
the flow-control-receive-window after the fact?
Can you explain?
-=R

On Thu, Dec 13, 2012 at 12:59 PM, Jonathan Ballard <[email-masked]>wrote:

>> *From:* Jonathan Ballard [mailto:[email-masked]]
>> *…*****
>>
>> ** **
>>
>> After I read it the question that was left was, "where is the debit
>> rule?" If that question doesn't make sense then maybe "credit" isn't the
>> real number word for flow control.
>>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 18 Dec 2012 08:07:09 +0100

Hi,

On Thu, Dec 13, 2012 at 04:43:57AM +0000, Gabriel Montenegro wrote:
> 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.

I like it, it sets the basic principles that implementations should follow
and will probably allow very simple implementations to coexist with complex
ones, just like TCP does.

This could be a nice addition to the spec, good job guys !

Willy