RE: detecting connection speed

>From this meeting:
http://lists.w3.org/Archives/Public/public-web-perf/2012Nov/0014.html


In this section of the meeting notes:
http://www.w3.org/2012/11/08-webperf-minutes.html#item14
HTTP Client Hints for Content Adaption without increased Client Latency


And I agree there are far more moving pieces in the network scenario. Given that we acknowledge so many things can change and that the metric could change on a page by page basis on mobile devices, what level (percentage) of accuracy do we need to shoot for to rely on this feature? If it was accurate for 80% of users, on mostly fixed connections, but wrong 20% of the time, mostly for mobile, would you use this to change the flow of your site?

What accuracy threshold has to be met before you'd rely on this hint? If we think we can meet that goal, then it is easier to move forward with the conversation.

Aaron



From: Mark Watson [mailto:watsonm@netflix.com]
Sent: Wednesday, December 4, 2013 8:40 AM
To: Aaron Heady (BING AVAILABILITY)
Cc: Luke Blaney; Puneet Mohan Sangal; James Graham; Philippe Le Hegaret; public-web-perf@w3.org
Subject: Re: detecting connection speed



On Wed, Dec 4, 2013 at 8:32 AM, Aaron Heady (BING AVAILABILITY) <aheady@microsoft.com<mailto:aheady@microsoft.com>> wrote:
This is taking a very similar track to the conversation about having the UA return more details about the screen resolution. That simply does account for the many ways a user can change the meaning of the resolution. Do they have the screen zoomed? Is it a giant screen, but being looked at from across the room... it goes on with just about as many gotcha's as the connection speed conversation.

Could you point me at that discussion ? Sounds interesting.

I actually think it is qualitatively different from the connection speed issue. Information about the physical screen resolution and physical screen size may well be present at the client and information about the typical viewing distance may also be implicit in the type of device (think TV vs laptop). Thus there are many cases where reasonable default behavior can be derived from those known physical properties. There is a problem right now, for example, because the definition of CSS pixel assumes a particular viewing distance.

On the other, hand, network performance depends on many many things which are unknowable by the client device - what's on the other side of the WiFi, where is the server, what does the cross-traffic look like etc. etc.


For connection speed, maybe we should think of it more like progressive encoding of a streamed movie. You assume the worst connection speed (that you are willing to optimize for). It sets up the basic UI and if that was the actual speed it would most likely stop there as the larger components wouldn't download or could be timed out and further features not loaded. If they have a better connection, then some of the middle tier experience loads, but the full experience times out and stops loading. And obviously that last stage is everything is fast enough that nothing gets cut off and they get the full experience.

That's one option, though people with fast connection often prefer to get the full experience up-front, without having to wait though the low-end one.

...Mark


I'd say that more than two experiences, a basic experience (slow connection) or full experience (high enough connection), probably exceed most shops developer resources.

Aaron




From: Luke Blaney [mailto:luke.blaney@ft.com<mailto:luke.blaney@ft.com>]
Sent: Wednesday, December 4, 2013 8:09 AM
To: Puneet Mohan Sangal
Cc: James Graham; Philippe Le Hegaret; public-web-perf@w3.org<mailto:public-web-perf@w3.org>

Subject: Re: detecting connection speed

When you say "connection speed", what exactly do you mean?  Are you referring to just the first hop from the client?  Or all the hops the whole way to the server?

Just looking at the first hop can be misleading as it assumes that's where the bottleneck is.  This isn't always the case, particularly on personal wifi hotspots (which use wifi for the first hop, but 3g for the second) or captive portals (which can use wifi for the first hop, but drop connections for the second)

Using the entire connection from client to server would provide a more accurate indicator (though still totally ignores the fact that conditions change over time). I guess this would be harder to implement as the User Agent would require a different value for every server it contacts.

On the whole, I think a better approach would be to not implement this API and encourage web developers to think "Offline First".


On 4 December 2013 05:05, Puneet Mohan Sangal <pmsangal@yahoo-inc.com<mailto:pmsangal@yahoo-inc.com>> 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?

Phillipe, how can we obtain more info on Network Information API status?

Cheers,
Puneet



From: James Graham <james@hoppipolla.co.uk<mailto:james@hoppipolla.co.uk>>
Date: Tuesday, December 3, 2013 9:46 PM
To: "public-web-perf@w3.org<mailto:public-web-perf@w3.org>" <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Subject: Re: detecting connection speed
Resent-From: <public-web-perf@w3.org<mailto:public-web-perf@w3.org>>
Resent-Date: Tuesday, December 3, 2013 9:47 PM

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.






--
Luke Blaney
Labs developer, FT Labs [labs.ft.com<http://labs.ft.com> | 0870 085 2038 | @ftlabs]


________________________________
This email was sent by a company owned by Pearson plc, registered office at 80 Strand, London WC2R 0RL.  Registered in England and Wales with company number 53723.