W3C home > Mailing lists > Public > public-web-perf@w3.org > December 2013

Re: detecting connection speed

From: James Graham <james@hoppipolla.co.uk>
Date: Wed, 04 Dec 2013 16:38:19 +0000
Message-ID: <529F5A7B.8000307@hoppipolla.co.uk>
To: public-web-perf@w3.org
On 04/12/13 16:29, Mark Watson wrote:
> On Wed, Dec 4, 2013 at 2:51 AM, James Graham <james@hoppipolla.co.uk
> <mailto:james@hoppipolla.co.uk>> wrote:
>     On 04/12/13 05:05, Puneet Mohan Sangal wrote:
>         James, I understand it's a difficult problem to solve, however
>         it will
>         be a very useful dimension when conducting analysis on
>         performance data.
>         May be we should start with what the possible solutions could
>         be, and
>         then consider the pros & cons?
>     You should always start with use cases, because they form the basis
>     for determining what the pros and cons of possible solutions are. If
>     possible you should also back up use cases with evidence that they
>     are real problems e.g. people using workarounds to try and solve the
>     use case in the absence of a built in solution. In this case that
>     might be e.g. authors timing resource downloads to try to estimate
>     connection speed.
> Timing resource downloads is a more direct measure of the only (or at
> least main) property of interest - the achievable performance on the
> current network connection, from a particular server and at the current
> time. Adaptive streaming applications, for example, make extensive use
> of resource download timing - directly or indirectly - to determine the
> appropriate video rate to request.

Right, adaptive streaming is a good example of where this kind of thing 
is useful (and afaik, already solved). In that case it works because the 
resource you are downloading is time-based so you can dynamically adjust 
your requested bitrate according to small-timescale data on network 
conditions. Since most other resources aren't like audio/video in this 
respect, the same approach wouldn't work. Hence the importance of 
defining use cases upfront rather than talking about solutions. (To be 
clear, I remain skeptical on general grounds that, even in the presence 
of use cases, there will be solutions that do more good than harm, but 
it is hard to be sure).
Received on Wednesday, 4 December 2013 16:38:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:37 UTC