Subject: http/2 flow control

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 14:22:21 -0800

Given the long previous debates in flow control discussions on the
spdy-dev@ mailing list
(https://groups.google.com/d/topic/spdy-dev/JB_aQPNI7rw/discussion), I
thought it would be useful to write up a summary of lots (but not all)
of the discussions before we engage in the f2f interim meeting
discussions. Here's my summary:
https://docs.google.com/document/d/15LMnvVWSY-kF-ME4RZIFHN0FukViapjiefQMmQCnr14/pub.

It discusses the reasoning behind per-stream flow control windows, as
included in SPDY3 and in the current http2 draft. It discusses some
problems with it, and also tradeoffs between relying on transport
level flow control windows (TCP) and session level flow control
windows.

This document left out some other proposals to hopefully keep it simpler:
* Receiver sending a xon/xoff frame to instruct the sender to
resume/stop sending.
* Stream group flow control windows.

The latter is fairly advanced, and I think it is only pertinent if we
agree there is a need for session level flow control windows, since
stream group flow control windows subsume session level flow control
windows (session == a single stream group containing all streams).

One last thing on flow control. It's definitely possible, as Patrick
demonstrates in
http://bitsup.blogspot.com/2012/12/managing-bandwidth-priorities-in.html,
to use flow control facilities to control prioritization. It's my hope
that HTTP/2's prioritization facilities will suffice for that end, and
thus we won't try to use receive windows to control prioritization.

Cheers.

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 16:31:25 -0600

Quick question: is the flow control in SPDY 3 like SSHv2's?  I.e.,
with per-flow window sizes advertised by the receiver?

I ask because this has caused serious problems in the SSH world.  I
don't want HTTP/2.0 to make the same mistakes.

Nico
--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:36:40 -0800

Will's naming in his email wasn't the best :)

Flow control in SPDY3 was flawed and didn't work. It was solely per-stream
flow control.
What is proposed in his writeup fixes this flaw relatively simply. The most
relevant line is:

It’s important to recognize that stream and session flow control serve two
separate roles. Session flow control helps manage the memory consumption
per session, whereas stream flow control helps manage what portion of that
that memory an individual stream is allowed consume.

I suggest reading the doc, though!
-=R

---

From: Nico Williams <[email-masked]>
Date: Fri, 25 Jan 2013 01:18:18 -0600

> Flow control in SPDY3 was flawed and didn't work. It was solely per-stream

Right, that would fail similarly to SSHv2's.

> separate roles. Session flow control helps manage the memory consumption per
> session, whereas stream flow control helps manage what portion of that that
> memory an individual stream is allowed consume.

Ah, excellent and very clever.  I believe that should work.

> I suggest reading the doc, though!

Sure.  Thanks for picking just the right paragraph to quote.

Nico
--

---

From: Mike Belshe <[email-masked]>
Date: Mon, 28 Jan 2013 14:41:52 +0900

Nice writeup, will.

I guess if you wanted to note one more thing, the (max streams * default
per stream window) is potentially a type of flow control too, depending on
values chosen.

Mike