Re: Pipelining Control Proposal

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" <kzyp@sitepen.com>
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: <public-webapi@w3.org>; "Mark Baker" <distobj@acm.org>
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();
> xhr1.open("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
> xhr2.open("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.
>
> Thanks,
> Kris
>
>
>

Received on Wednesday, 2 April 2008 04:04:49 UTC