W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: Pipelining Control Proposal

From: Kris Zyp <kzyp@sitepen.com>
Date: Mon, 3 Mar 2008 11:22:11 -0700
Message-ID: <00a401c87d5b$806c8270$4200a8c0@kris>
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: <public-webapi@w3.org>, "Mark Baker" <distobj@acm.org>

I wanted to propose another way to deal with the usability issues involved
with pipelining in combination with long-lived responses for the purposes of
server initiated messages. This is not an opposition to HTTP improvements
for declaring extra connection limits. I hope that happens for the broader
benefit that it provides and that HTTP improvements can solve the two-
connection limit probem, however as I articulate in the reasons at the 
HTTP improvements are simply not sufficient for avoiding pipeling issues,
and a simple mechanism for providing connection advise is critical as well. 
believe this is a very minimalistic approach only adds a trivial amount of
complexity to the XMLHttpRequest spec and has almost zero required
implementation burden. The addition property defined here can be used
by user agents to deal with the problem of responses becoming indefinitely
queued due to being pipelined on a connection where a previous response
is never finished or simply takes a long time.

I propose that we have define a property called "durability" to the
XMLHttpRequest object, that can be assigned a positive number (x >= 0) by
authors that want to advise the user agent on how long they expect the given
request to last. A low value indicates that the request is expected to be
very quick and a high value indicates that the request is expected to take
longer. The "durability" property should default to 1, and so a value of 1
indicated a request with an average length of time. The durability property
can set and modified at any time before, during, or after a request. A user
agent is not required to behave in any particular way in response to the
durability property, it is simply a standard way for authors to provide
information about how long the response will probably take so that user
agents can utilize this information in making informed optimization 
and provide a means for intelligently avoiding indefinitely queued

There are no requirements for how the user agent responds to this property,
but it is recommended that user agents use this information to help optimize
pipelining (and potentially connection limiting). The lower the durability 
the faster the request is likely to receive a response, and therefore the
corresponding connection is a better candidate for pipelining if that is
enabled in the user agent. The higher the durability value, the slower the
request is likely to receive a response, and therefore a high durability
value indicates that the connection is a poor candidate for pipelining. A
very high durability value (>100) indicates that the response may be so slow
in coming that it may be advisable for the connection to not be counted
against the two-connection limit (but this is not required, and I am 
willing to concede HTTP as the primary advisor for connection limit

This can be used by user agents to avoid the problem of responses
becoming indefinitely queued due to being pipelined on a connection where
a previous response is never finished.

Authors could also leverage user agents that follow the recommendations in
the proposal to create high-efficiency duplex communication channels (by
setting low durability values to attract pipelining).

Below is an example of usage of "durability":

var xhr1 = new XMLHttpRequest();
xhr1.durability = 1000; // this response may take a long time to return,
user agents may not want to pipeline here
xhr1.durability = 0.1; // now a fast response is indicated, this connection
may be a good candidate for pipelining now
var xhr2 = new XMLHttpRequest(); // the author has effectively recommend
that this request be pipelined on the connection used by xhr1

Once again this is not proposal for pipelining to be implemented through
XHR, nor a requirement that connection limits be increased, it is merely a
channel for advice to be passed that a user agent can utilize if it desires.
There are a number of reasons why allowing XHR advice is better than
completely deferring all advice to be provided by HTTP response headers:

1. The advice can be immediately available. Responses headers are not
available until received from the server, and in the meantime, advice can be
very relevant in helping to optimize pipelining. In particular, HTTP
response advice simply can not solve the problem of pipelining requests
behind long-lived responses resulting in indefinitely queued responses. If a
browser is pipelining requests, and a response is long-lived, it may attempt
to pipeling requests before receiving response headers indicating that
pipelining is not a good choice with the current response. The browser
simply has no information to suggest otherwise if it only comes through
response headers.

2. Advice can be altered during the life of the request/response. A response
header can only offer a single piece of advice, but XHR durability advice
can change, and the durability value can be lowered if the author knows that
a response will be received shortly. This can provide information that the
user agent may not be able to determine.

3. If browsers implemented pipelining and observed the recommendations for
pipelining, this opens the doors for true duplex communication on a single
TCP channel. Server-initiated messaging techniques are essentially efforts
to provide asynchronous duplex communication between the client and server.
However, currently all mechanisms for this rely on two TCP connections,
despite the fact TCP is fully duplex, and duplex communication is possible
with HTTP as well. I believe we would be remiss in not looking to the future
and considering how we can be moving towards a solution where authors can
achieve duplex communication efficiently; on a single connection. This
proposal provides that pathway. If there are any other mechanisms for doing
this, I would love to hear about them, but I do not know of any, and all
current techniques for server-initiating messaging (including the HTML 5
server-sent events) require two TCP connections for asynchronous duplex
communication (I would definitely be more interested in HTML5 server-sent
events if they did have some trajectory towards duplexity).

4. HTTP advice and XHR advice do need to be at odds. The
proposal is to have a standard property that can be used for heuristics, and
if HTTP adds a response header for advice, both sources of information can
be used for further improving heuristics.

5. This advice is useful for more than just indefinitely long-lived 
(as used with server initiated messaging), but could be extremely useful
in advising about responses that are known to take take a long time to be
processed on the server, so user agents could avoid pipelining behind
such requests.

6. Since this is simply an optional property for the sake of advice, 
authors could immediately begin adding this advice to XHR requests, and
browser vendors could experiment with different ways of observing the
advice, at their own convenience, without having divergent APIs.
Experience based on implementation then might possibly lead to more
concrete requirements for observing the advice in the future.

This proposal addresses the issues from the "Pipelining Control" proposals 
in a
very minimalistic form (and browsers could potentially use the advice to 
connection limit problems if they so desired), and the I hope this is a
reasonable compromise for improving the XHR.

Received on Monday, 3 March 2008 18:28:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 3 March 2008 18:28:46 GMT