[jsr369-experts] Re: [servlet-spec users] Re: HTTP 2.0 specific configuration parameters in the API?

From: Wenbo Zhu <wenboz_at_google.com>
Date: Mon, 29 Sep 2014 11:46:10 -0700

On Wed, Sep 24, 2014 at 11:56 AM, Greg Wilkins <gregw_at_intalio.com> wrote:

> On 23 September 2014 04:11, Wenbo Zhu <wenboz_at_google.com> wrote:
>> IMO - there are two styles to support flow-control for any async API, on
>> either the client or server side.
>> The first style requires the client and server to handle effectively what
>> TCP does. There are many issues, e.g. the API is complicated, and worse,
>> per-stream flow control isn't necessarily what the application wants, and
>> it's very hard to identify an optimal window size, either at run-time or at
>> design time.
>> The 2nd style: for reads, it requires the application to signal to the
>> "I/O" layer whenever the application is ready for more data; and for
>> writes, it requires the I/O layer to signal to the application whenever the
>> I/O is ready for more data. Whether the flow-control done at the
>> stream-level (as transport protocols) or at the process level is
>> transparent to the API/application.
>> Lastly it is impossible to have transparent flow-control. E.g. the fact
>> that the WebSocket (client) API lacks flow-control can't be remedied at the
>> I/O or protocol level.
> Wenbo,
> I don't think it is workable to allow applications to have undue influence
> over flow control. Essentially flow control is a fairness mechanism to
> ensure that scarce resources are shared between competing concerns.
> Unfortunately application developers/deployers are not the most objective
> parties to determine relative priorities of traffic and most will not
> voluntarily give up capacity so that other potentially unrelated concerns
> can proceed.
> Thus I think any API that allows applications to set window sizes could
> expect to see Integer.MAX_VALUE passed frequently.

> I think that transparent, or at least mostly transparent flow control is
> our only real option. If an applications reads or writes more data than is
> available either in the TCP windows or the h2 windows it will simply block
> (or asynchronously wait) until it can proceed.

I thought I was proposing the same:
1) synchronous APIs: blocking - so completely transparent
2) async APIs: some kind of signals for the app, as a writer or reader, to
interact with the container run-time to stop/continue delivery, when the
flow-control decisions are completely made by the container.

> But that is not to say that applications might not be able to contribute
> some information that will allow a more intelligent implementation of flow
> control. So there are a few parameters that a flow control algorithm can
> adjust:
> - absolute size of connection window. ie how much resource is the
> container prepared to commit to a single connection.
> - absolute size of stream window. ie how much resource is the
> container prepared to commit to a single request/response cycle
> - Window hysteresis. how eager should the container be to replenish a
> declining window? should it send window updates on every byte consumed, or
> should it let the window drain for some size/time constrain before
> replenishing.
> Factors that inform how these parameters are set include:
> - expected and/or enforced max/mean connections per server.
> - expected and/or enforced max/mean concurrent streams per connection
> - max/mean request/response body size
> - max/mean write/read size
> - network/connection capacity
> To discover these factors, there are a number of approaches that can be
> taken:
> 1. These can be considered all a matter for deployers, who should know
> their applications deployed thus the factors above, so they will set
> appropriate flow control parameters.
> 2. Applications can declare values for the factors above that can be
> used to heuristically set the flow control parameters. This will involve
> trusting that applications will declare realistic values.
> 3. Containers can measure the factors of the deployed application(s)
> and dynamically adjust the flow control parameters.
> Personally, I'm not sure we know enough about flow control yet to do much
> more that 1. Ideally we could work towards 3., but I'm yet unsure if we
> will need any values that an application may declare in 2.

These are interesting topics. I haven't had too much thought on how to
generalize them, and happy to discuss any proposals.


> cheers
> --
> Greg Wilkins <gregw_at_intalio.com>
> http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that
> scales
> http://www.webtide.com advice and support for jetty and cometd.