Re: Proposal to measure end-user latency

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 » <nilsson@opera.com> a écrit :

>On Tue, 03 Sep 2013 17:32:04 +0200, Sébastien BARNOUD
><sebastien.barnoud@prologism.fr> wrote:
>
>> 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.
>>
>
>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/
>

Received on Tuesday, 3 September 2013 16:19:30 UTC