RE: detecting connection speed

As a basic idea for this issue, would it be better if we:

1.       Update the UA to do all of the tracking and computations about 'speed' and then send a final computed hint from its point of view?

OR


2.       Update the UA to make available all of the statistics, which would then be downloaded via beacon and the origin would do the math to determine 'speed'.


#1 distributes the work and tracking on to the client, costs less network resources (no beacons), but makes it hard to tweak over time (have to update the UA) and doesn't allow for custom data mining.

#2 exactly the opposite of #1. Less load on the client, more beacons, every shop can/will build their own logic to determine speed, any kind of data mining possible.

Aaron



From: Ilya Grigorik [mailto:igrigorik@google.com]
Sent: Wednesday, December 4, 2013 3:04 PM
To: Aaron Heady (BING AVAILABILITY)
Cc: Jatinder Mann; James Graham; public-web-perf@w3.org
Subject: Re: detecting connection speed

Somewhat of a tangent...

There have been multiple requests in the past to expose the "bytes transferred" as part of Nav/Resource Timing API. While this is not a panacea, I do think it would be valuable and could address a lot of use cases we're discussing here... Or, to be more precise, give the developers the basic primitive to then build up their own abstractions to drive BW-estimation and similar use cases.

</tangent> :)

On Wed, Dec 4, 2013 at 11:44 AM, Aaron Heady (BING AVAILABILITY) <aheady@microsoft.com<mailto:aheady@microsoft.com>> wrote:
We look at data over time to create buckets of IP ranges that are very reliably in high or low performance ranges. That could take into account the RTT or page load provided by W3C timing, the page load time as detected by JavaScript clocks, specific tests by downloading and measuring the classic fixed size object and looking at network statistics, etc. Deciding how to apply that knowledge is a whole different can of worms.

In my experience, determining it on a per request basis just has too much variance. Maybe if the UA kept its own set of statistics on a per origin IP + current default gateway basis and knew that it was generally good or bad for a given connection pair then it could pass that hint along, maybe include a confidence hint with it (fast last 99 of 100 connections). If that mobile device thinks it is always fast to an IP given its current proxy, then it most likely is.

Aaron



-----Original Message-----
From: Jatinder Mann [mailto:jmann@microsoft.com<mailto:jmann@microsoft.com>]
Sent: Wednesday, December 4, 2013 11:20 AM
To: James Graham; public-web-perf@w3.org<mailto:public-web-perf@w3.org>
Subject: RE: detecting connection speed

I generally agree with James that this is a difficult problem to solve. I'd love to hear use cases and how this data will actually help.

Something not made clear in this thread is are we asking for data to make runtime decisions or historical data for post processing like the Timing APIs? If post processing, what do you plan to achieve with the data considering the variability, e.g., a single browsing session could have been on many different connection speeds? Are you trying to make some sort of correlation like most of your users appear to be on 3G so you'll optimize your site for that type of user?

Jatinder

-----Original Message-----
From: James Graham [mailto:james@hoppipolla.co.uk<mailto:james@hoppipolla.co.uk>]
Sent: Tuesday, December 3, 2013 8:16 AM
To: public-web-perf@w3.org<mailto:public-web-perf@w3.org>
Subject: Re: detecting connection speed

On 03/12/13 16:04, Philippe Le Hegaret wrote:
> On Wed, 2013-11-27 at 09:38 +0000, Puneet Mohan Sangal wrote:
>> Is there any ongoing work in detecting connection speed, as part of
>> this group?
>> See http://www.w3.org/TR/system-info-api/#network and
>> http://www.w3.org/2012/11/performance-workshop/report.html#i4
>>
>
> The short answer is no one is working on it in the web performance
> working group at the moment. I don't quickly see any visible progress
> on the Network Information API for the past 12 months but you may want
> to ask them if there were progress or not.

Detecting connection speed in a useful way is a very difficult problem, not least because it's often a time varying quantity (consider a mobile device that might switch between wifi, 3G, 3G but with high packet loss, and no signal at all, all in the course of interacting with a single page). I think that in general trying to expose this kind of data can lead to worse user experiences than not exposing it (e.g. if pages erroneously shift into some sort of "low bandwidth" mode due to some temporary network congestion or whatever). Therefore I don't think this should be something that we expose, unless it is clear that we can do it in a good way that will solve actual problems.