atom feed9 messages in org.w3.public-webapiRe: Pipelining Control Proposal
FromSent OnAttachments
Kris ZypFeb 19, 2008 7:55 am 
Jonas SickingFeb 19, 2008 10:26 am 
Kris ZypFeb 19, 2008 10:37 am 
Anne van KesterenFeb 19, 2008 2:30 pm 
Kris ZypFeb 19, 2008 2:50 pm 
Kris ZypFeb 19, 2008 3:58 pm 
Jonas SickingFeb 19, 2008 4:25 pm 
Kris ZypMar 3, 2008 10:22 am 
Kris ZypApr 1, 2008 9:03 pm 
Subject:Re: Pipelining Control Proposal
From:Kris Zyp (
Date:Apr 1, 2008 9:03:04 pm

Do we have any other ideas for how to deal with pipelined requests being indefinitely queued behind long-lived responses, or does this proposal for an optional advice property seem like an approach we could consider? Thanks, Kris

----- Original Message ----- From: "Kris Zyp" <> To: "Jonas Sicking" <> Cc: <>; "Mark Baker" <> Sent: Monday, March 03, 2008 12:22 PM Subject: Re: Pipelining Control Proposal

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 bottom, HTTP improvements are simply not sufficient for avoiding pipeling issues, and a simple mechanism for providing connection advise is critical as well. I 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 decisions, and provide a means for intelligently avoiding indefinitely queued requests/responses.

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 value, 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 certainly willing to concede HTTP as the primary advisor for connection limit overriding).

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();"GET","chat",true); xhr1.durability = 1000; // this response may take a long time to return, user agents may not want to pipeline here xhr1.send(null); .... 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"GET","resource",true); xhr2.send(null);

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 responses (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, JavaScript 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 alleviate connection limit problems if they so desired), and the I hope this is a reasonable compromise for improving the XHR.