Re: Proposal to measure end-user latency

The W3C specification is a perfect example of what could be done at the
application layer. "User experience" is made of server response time (of
many objects), network latency, rendering, Š And should be computed and
measured at the application layer.

But consider, per example a SOA architecture (HTTP is not only used by Web
browsers). No Javascript client side. Of course, the client/server SOA can
build its own measurement solution.

In practice, it is extremely rarely done. When problem occurs, you don't
have a lot a solution to investigate (some sophisticated network agent,
Š), if SSL is used it becomes even harder.

The goal of my proposal is to procure a minimal set of measurements. Flow
control is a hard issue, where mechanism can produce worst effects than
what they should protect.
To my point of view, the most measurement you have, the most control you
can offer, and the quicker you are able to diagnose disfunction.

So, I agree with you to let the application layer free to measure and
convey the information the way it wanted.
To my mind, it is not a reason to not measure and convey, at the protocol
layer, the protocol metrics.

Le 03/09/13 20:29, « Martin Thomson » <martin.thomson@gmail.com> a écrit :

>On 3 September 2013 11:23, Willy Tarreau <w@1wt.eu> wrote:
>> propose browsers to upload their feedback using HTTP headers
>
>There are a few web performance specifications coming out of the W3C
>Web Performance working group that should facilitate this sort of
>thing.
>
>http://www.w3.org/TR/hr-time/
>http://www.w3.org/TR/navigation-timing/
>
>I don't see how HTTP/2.0 is special in this regard (other than the
>fact that it might reduce those numbers in some cases).  Honestly, I
>really don't want a standard for how to convey this information.  It's
>just not good standardization business, because proscribing how to
>convey this is only going to get ignored anyway, even if it was a good
>idea.

Received on Tuesday, 3 September 2013 20:40:20 UTC