Subject: Proposal to measure end-user latency

From: Sébastien BARNOUD <[email-masked]>
Date: Tue, 03 Sep 2013 17:32:04 +0200

Hi,

I've carefully read the goals of HTTP 2.0 and the present draft (version 6).
 
I would like to propose the following idea to the WG : Measure the end-user
perceived latency by including in the protocol the ability to send to the
server the response time measured by the client application.
 
Of course, the related additional message will introduce some overhead.
Thus, this feature could be optional and driven by some headers fields or
other means.
 
The benefit will be to correlate server and client elapsed time for
monitoring purpose and to evaluate the end-user perceived response time.
 
Today, this kind of measurement is achieved at the application layer and
sent to dedicated sites. My proposal is to introduce, directly in the
protocol, a mean to send this information back to the server.

Best regards,

Sebastien Barnoud

---

From: "Martin Nilsson" <[email-masked]>
Date: Tue, 03 Sep 2013 18:05:17 +0200

> protocol, a mean to send this information back to the server.

Exactly what are you measuring though? If it is the delivery of a specific  
resource, TCP gives a good view of that. If you are talking about multiple  
resources aggregated into a "page", then you pretty much need to measure  
it at application layer, because you need a definition of "page" (and  
"done").

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: Sébastien BARNOUD <[email-masked]>
Date: Tue, 03 Sep 2013 18:19:01 +0200

I agree for the "page" view, it is much more an applicative concern (even
if it interests a lot of people).

My proposal was for the "hit" view. I disagree with you, TCP doesn't give
you a so good view (it's only good for the first hop).

Le 03/09/13 18:05, « Martin Nilsson » <[email-masked]> a écrit :

>> I've carefully read the goals of HTTP 2.0 and the present draft
>>(version  
>> 6).

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Sep 2013 09:41:14 -0700

On 3 September 2013 08:32, Sébastien  BARNOUD
<[email-masked]> wrote:
> sent to dedicated sites.

Is this somehow inadequate in some way?

---

From: Sébastien BARNOUD <[email-masked]>
Date: Tue, 03 Sep 2013 19:07:22 +0200

To my mind, it would be relevant to have the "client view" directly on the
server and with the ability to correlate client and server response time
at a single point.

Application layer (like Google Analytics or any other) doesn't address
real-time IT monitoring. You can always develop your custom application.
Anyway, if the protocol offers directly this kind of service, it could be
useful (always to my mind) and simpler and probably will need less
band-width than a "home made" solution.

A lot of IT have performance problems, end-user complains, and in the same
time server statistics are pretty good.

At least, having the "client view" statistics allows people to speak about
the same measure. Just that, is an improvement.

An other example, Apache starts to measure the response time once he
accepts the request and have a "ready" worker. How many time did you spend
in the listen queue ? This king of me sure could help you to better
monitor the flow.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Sep 2013 11:11:29 -0700

On 3 September 2013 10:07, Sébastien  BARNOUD
<[email-masked]> wrote:
> You can always develop your custom application.

You are right.  But you didn't answer my question.  How is an
application layer solution inadequate?

Arguably, it's superior because it can also measure other factors that
the protocol cannot.

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 3 Sep 2013 20:23:35 +0200

Hi Martin,

> application layer solution inadequate?

It is not inadequate, it is different. What I'm noticing is that
server-side software has no idea what response times are and worse,
what the transfer time is. Some companies develop client-side gadgets
to provide this feedback to the server, but all in all very few web
sites rely on such techniques and have a measurement of their response
time.

So the result is that server-side software has no clue what their
response time is nor how it variates with time and load. I had to
put timers in haproxy precisely to provide this information, but
that does not cover the transfer time, and (unfortunately) not
everyone uses haproxy yet :-)

> Arguably, it's superior because it can also measure other factors that

100% agreed, I'm tempted to balance between seeing a strandard way to
propose browsers to upload their feedback using HTTP headers (but with
what request, when, and measure what) and maybe suggesting a standard
method for a sender to measure the time it takes to flush a complete
window. The first one is accurate but not easy to report nor easy to
standardize. The second one only covers transport (not response time)
but allows the server to measure the time taken by the transport.

Probably something useful would be between the two, maybe have the browser
measure the time elapsed between a request is sent and the first bytes
start flowing back and report that using very few bytes of protocol in
the other direction could be useful.

I'm sure that adding such metrics can provide many useful help to improve
overall user experience, but it's not obvious to me how.

Willy

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Sep 2013 11:29:02 -0700

On 3 September 2013 11:23, Willy Tarreau <[email-masked]> 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.

---

From: Sébastien BARNOUD <[email-masked]>
Date: Tue, 03 Sep 2013 22:39:48 +0200

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.

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Sep 2013 13:49:22 -0700

I've also wanted this-- this would allow servers to perform automatic
testing/analysis without requiring content writers to add code. This is
desirable for doing things like changing the order/frequency of server
push, etc.
This would be something in addition to what is available at the application
layer.
In particular, a server could add a header indicating that it would like to
see the WebTiming results for the page POSTed to a particular URI after
some condition (e.g. X seconds, X resource loaded, etc) had been met.

Despite the fact that I believe this is truly useful, I believe also that
this is probably not the right place to standardize such a thing-- I
believe the W3C is.

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 3 Sep 2013 22:56:59 +0200

Hi Roberto,

> this is probably not the right place to standardize such a thing-- I

It depends if it's done at the protocol level or higher in fact. For example
TCP uses timestamps for exactly the same reason and they're conveyed inside
the protocol itself. I think it could be the W3C as you suggest if we find
that it's too application-oriented to be related in any way with the protocol.
Eg. if the protocol as no reason to know about this of course I'd agree. But
if the protocol leaves a room for a timestamp or whatever, then it makes sense
to have it here. The role of intermediaries would also have to be discussed.

Best regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Sep 2013 15:56:49 -0700

I'd imagine that you'd want to re-use the same timing information that is
collectable within the javascript, and likely in the same format (that just
makes sense from an engineering perspective).
That format and when each of the timestamps is collected is currently
defined in the W3C.

I'd just ask them to trigger the collection of that data collection upon
the condition stated in the header.
The interaction with HTTP would just be to add that header to the IANA
registry, if so... doesn't seem very likely to require this WG.

-=R

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Sep 2013 07:00:09 +0200

> registry, if so... doesn't seem very likely to require this WG.

If it'd be done that way, I totally agree.

Cheers,
Willy

---

From: Sébastien BARNOUD <[email-masked]>
Date: Wed, 04 Sep 2013 14:46:29 +0200

My proposal wasn't to have an interaction between the application layer
and the protocol. So, I also agree.

My proposal is to have an optional measurement at the protocol level
itself. Uses cases could be for protocols over HTTP, like SOAP to have
automatically a minimal set of measurements without extra coding at
application layer.
Of course, it will be available for a HTML application that doesn't
implement any measurement at the application layer which, although it is
regrettable, is often the case.

However, it is true that a protocol is not there to overcome all the
misery of the world.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 4 Sep 2013 08:45:22 -0700

I suppose the question here then is how much better these (client-side)
measurements are as compared to what the server can observe and generate on
its own, and what attack vectors this information might possibly
allow/enhance.
On Sep 4, 2013 5:46 AM, "Sébastien BARNOUD" <[email-masked]>

---

From: Mike Belshe <[email-masked]>
Date: Wed, 4 Sep 2013 09:19:31 -0700

I love the idea of metrics.  I think the only thing I love more is
simplicity.

I think the choices for measuring latency out-of-band from the protocol
itself are numerous - so this ends up just being more stuff.

The debate about what-to-measure, how-to-measure, etc would be very
lengthy.

Mike

On Wed, Sep 4, 2013 at 8:45 AM, Roberto Peon <[email-masked]> wrote:

> On Sep 4, 2013 5:46 AM, "Sébastien BARNOUD" <
> [email-masked]> wrote:
>

---

From: Sébastien BARNOUD <[email-masked]>
Date: Wed, 04 Sep 2013 18:31:27 +0200

To my point of view, the main benefits are monitoring, diagnostic, impact
analysis:
-) You see, server side, the average response time of a particular component
increasing: the first question the business ask is: "what is the client
impact?".
-) In some situation, you can also see client response time increasing while
every things is normal at the server level.

I don't have any idea on attack vectors.

De :  Roberto Peon <[email-masked]>
Date :  mercredi 4 septembre 2013 17:45
À :  Sébastien  BARNOUD <[email-masked]>
Cc :  Willy Tarreau <[email-masked]>, HTTP Working Group <[email-masked]>,
Martin Thomson <[email-masked]>
Objet :  Re: Proposal to measure end-user latency

---

From: Sébastien Barnoud <[email-masked]>
Date: Thu, 5 Sep 2013 08:04:36 +0200

I love both. Out of bound measure is not simple in all cases ( per example with strong auth and complex PKI, for health application, ...).
What and how to measure?
Of course, DNS lookup, connect time, time to first byte, ... are interesting but it may use a lot of bandwidth. 
So, let say that people who need all that do it at application layer (like W3C specify it), and simply measure the total elapse time from DNS (if any) to last byte. 

Le 4 sept. 2013 à 18:19, Mike Belshe <[email-masked]> a écrit :

> I love the idea of metrics.  I think the only thing I love more is simplicity.  
> 
> I think the choices for measuring latency out-of-band from the protocol itself are numerous - so this ends up just being more stuff.
> 
> The debate about what-to-measure, how-to-measure, etc would be very lengthy. 
> 
> Mike
> 
> 
> 
> I suppose the question here then is how much better these (client-side) measurements are as compared to what the server can observe and generate on its own, and what attack vectors this information might possibly allow/enhance.
> 
> On Sep 4, 2013 5:46 AM, "Sébastien BARNOUD" <[email-masked]> wrote: