- From: Roberto Peon <grmocg@gmail.com>
- Date: Fri, 21 Jun 2013 16:54:49 -0700
- To: Fred Akalin <akalin@google.com>
- Cc: Jeff Pinner <jpinner@twitter.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAP+FsNeRN1ar-yzorDNSYDkUsgKQnHL+wGTaaXGFV=fRLwrKGg@mail.gmail.com>
one big red flow-control button: Works for me. Setting 2^32-1 isn't necessarily "simple"-- 4+Gb files are common enough these days and would mess up a simple wget like tool. -=R On Fri, Jun 21, 2013 at 4:23 PM, Fred Akalin <akalin@google.com> wrote: > I agree with this. If implementation simplicity is the only reason for > disabling flow control, then we may as well just have a big switch to turn > it all off. > > > On Fri, Jun 21, 2013 at 4:13 PM, Jeff Pinner <jpinner@twitter.com> wrote: > >> I agree that many simple clients may want to not keep track of flow >> control windows, and there are good reasons for them not to try. That being >> said, Section 3.6.2: >> >> Deployments that do not require this capability SHOULD disable flow >> control for data that is being received. >> >> is very different than providing per-stream disabling via SETTINGS or >> WINDOW_UPDATE frames. Maybe the thing to do here is to not provide so many >> knobs (per-stream / all streams / connection / all of the above) and only >> allow the client to turn off flow-control completely? >> >> >> On Fri, Jun 21, 2013 at 3:49 PM, Martin Thomson <martin.thomson@gmail.com >> > wrote: >> >>> On 21 June 2013 14:58, Fred Akalin <akalin@google.com> wrote: >>> > Reading the "Ending Flow Control" section of the spec (3.8.9.4: >>> > http://http2.github.io/http2-spec/#EndFlowControl ), I'm wondering if >>> we >>> > even need the ability to disable flow control at all. >>> >>> This is something that we discussed at some length in the Tokyo >>> interim. Getting flow control right is hard. An implementation will >>> screw itself if it doesn't take a great deal of care. Flow control >>> always costs in performance, at best it just costs the bytes for a few >>> WINDOW_UPDATE frames; at worst, you end up with lots of periods where >>> you receive nothing but silence. Of course, the upside is that you >>> can get good concurrency without spending infinite amounts of RAM. >>> >>> This is why we included Section 3.6.2: >>> >>> http://http2.github.io/http2-spec/#rfc.section.3.6.2 >>> >>> Many simple implementations will choose to avoid flow control. In >>> fact, we want to encourage them to avoid implementing it. >>> >>> >> >
Received on Friday, 21 June 2013 23:55:16 UTC