W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

http/2 flow control

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Thu, 24 Jan 2013 14:22:21 -0800
Message-ID: <CAA4WUYgk-NPZ0bdYV3KysVED=OqFQ6Z0eE-7ePmmFdS2GMfjLA@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Thursday, 24 January 2013 22:22:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 22:22:56 GMT