- From: Jeff Pinner <jpinner@twitter.com>
- Date: Fri, 21 Jun 2013 18:01:38 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Roberto Peon <grmocg@gmail.com>, Fred Akalin <akalin@google.com>, Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CA+pLO_jgbKNYcr1bSbHfDb1y8MVohpzLpLm2=-yfZ74-mwYgkg@mail.gmail.com>
It may not by much in terms of saved complexity but what about transfer rate? What is the implication for the maximum transfer rate for long-latency connections? Assuming something to the effect of 100 ms one-way time and a client implementing a default strategy of updating the window after its half-consumed, with the default 64kB transfer window doesn't that limit the transfer rate to something like 320kB/s? It's back of the envelop math but I think it indicates that there is something to be gained by having the client disable flow control, besides a reduction in complexity. But I do think it should be a single switch, something that disables all receive windows for both streams and the connection, and that we shouldn't provide a mechanism to re-enable. On Fri, Jun 21, 2013 at 5:05 PM, William Chan (陈智昌) <willchan@chromium.org>wrote: > When we talk about reducing implementation complexity, it's important to > keep in mind that all implementations that want to interoperate need to at > least respect the receiver's flow control windows. I think the marginal > complexity to also assert static flow control windows is pretty minor. I do > agree that we don't want to encourage people to try to do "smart" > allocation of buffers and flow control windows, as that would add > significant extra complexity. > > So, yeah, I don't think disabling flow control windows buys us much in > saved complexity, but whatever. I don't feel too strongly. > > > On Fri, Jun 21, 2013 at 4:54 PM, Roberto Peon <grmocg@gmail.com> wrote: > >> 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 Saturday, 22 June 2013 01:02:06 UTC