Re: multiplexing -- don't do it

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