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

Re: detecting connection speed

From: Yoav Weiss <yoav@yoav.ws>
Date: Thu, 5 Dec 2013 12:18:07 +0100
Message-ID: <CACj=BEi6bnV3bCdEMaep05Pt5TDifZVSdbZ6-qdxpcPbtjv2pw@mail.gmail.com>
To: James Graham <james@hoppipolla.co.uk>
Cc: public-web-perf <public-web-perf@w3.org>
On Thu, Dec 5, 2013 at 12:04 PM, James Graham <james@hoppipolla.co.uk>wrote:

> On 05/12/13 10:51, Yoav Weiss wrote:
>> On Thu, Dec 5, 2013 at 11:17 AM, James Graham <james@hoppipolla.co.uk
>> <mailto:james@hoppipolla.co.uk>> wrote:
>>     On 04/12/13 23:04, Ilya Grigorik wrote:
>>         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...
>>     What use cases? I haven't actually seen a list of use cases people
>>     want solved anywhere in this thread yet. Without that it is
>>     impossible to tell if any particular API would be valuable or not.
>> I've previously raised it on the list [1]. The main use-case I see for
>> that is enabling RUM solutions to detect compression issues along the
>> path, with the side-effect of enabling authors to experiment with
>> client-side effective-bandwidth detection strategies.
> Apart from the first one, those aren't very concrete use cases. A concrete
> use case would be something like:
> "Youtube.com wants to serve video over the internet. In order to stream
> with minimal interruptions in the face of variable network conditions, it
> would like to dynamically adapt the bitrate of the streamed video to match
> the currently available bandwidth"
> Of course this is an already-solved use case, but it is good in the sense
> that it refers to a real problem that an actual site is having, not a
> problem that we think a hypothetical site might  be having, and sets out
> some clear parameters for deciding whether the solution is good enough
> (e.g. "solution must work for video", "solution must allow adaption in
> realtime", etc.)
I've misread your previous mail, and thought you're asking about use-cases
for adding "bytes transferred" to ResourceTiming. I don't have a concrete
use-case for the "bandwidth" attribute, even though I can think of some
non-concrete ones. I think exposing "bytesTransferred" in ResourceTiming
can enable authors to do crude BW detection on the client-side and let
concrete use-case examples evolve naturally.
Received on Thursday, 5 December 2013 11:18:38 UTC

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