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> 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]
> Sent: Wednesday, December 4, 2013 11:20 AM
> To: James Graham; 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]
> Sent: Tuesday, December 3, 2013 8:16 AM
> To: 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.
>
>
>