- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 02 Apr 2012 11:34:39 +1200
- To: <ietf-http-wg@w3.org>
On 02.04.2012 07:43, Peter Lepeska wrote: > On Sun, Apr 1, 2012 at 12:18 AM, Roberto Peon wrote: > <snip> >> >> In any case, do we believe that even an elightened and altruistic >> middleware provider can separate and distinguish between the hi-pri >> things >> within the one protocol effectively? I think that alone is a >> difficult >> problem... and thankfully probably out of the purvue of the WG. >> > > I think exposing browser-marked priority on HTTP objects to the > network is > a really great idea. And based on my experience, ISPs will gladly > take > advantage of this information to decrease page load times during peak > busy > hours for their users. > Indeed they will. Websites downloading without images, styles, or scripts until the second or third force-reload is a *very* common user complaint on some ISP here in NZ. From precisely that ISP enthusiasm. When the user traffic exceeds the upstream bandwidth queueing occurs, and the result is an almost steady stream of high priority requests, and a continual delaying of low priority ones until the client times out or aborts. I think there is a small factor which has been overlooked in this whole discussion about HOL and multiplexing. Cache latency. Given the presence of caching intermediaries its almost certain that a downstream cache closer to the client will encounter the scenario of choosing between a high priority request that is some (possibly hundreds) of ms RTT away and a low priority response that is immediately accessible in its cache. Blocking the cached response until the high priority can be found and transmitted would be damaging to the overall latency. Multiplexing is the only way to pause the low priority response when the high priority response starts arriving for delivery. To be fair IMHO the best thing for MUX nodes is to service all requests equally and interleave responses prioritised by order requested foremost and by availability second. Browsers etc can then prioritise the order of requests for whatever the local need is and expect that priority to be followed in a best-effort manner with any deviation performed being beneficial to overall latency. Chunking and interleaving of chunks by priority is not optional. AYJ
Received on Sunday, 1 April 2012 23:35:06 UTC