Re: Proposal to measure end-user latency

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 <grmocg@gmail.com>
Date :  mercredi 4 septembre 2013 17:45
À :  Sébastien  BARNOUD <sebastien.barnoud@prologism.fr>
Cc :  Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>,
Martin Thomson <martin.thomson@gmail.com>
Objet :  Re: Proposal to measure end-user latency


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"
<sebastien.barnoud@prologism.fr> wrote:
> 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.
> 
> 
> Le 04/09/13 07:00, « Willy Tarreau » <w@1wt.eu> a écrit :
> 
>> >On Tue, Sep 03, 2013 at 03:56:49PM -0700, Roberto Peon wrote:
>>> >> 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.
>> >
>> >If it'd be done that way, I totally agree.
>> >
>> >Cheers,
>> >Willy
>> >
> 
>