Re: Stats interface - Some comments on specific stats

On 09/19/2012 10:49 AM, Hutton, Andrew wrote:
> Hi Stefan,
>
> Although a snapshot can be useful I think we should have the ability
> to get some overall stats without the application having to poll for
> it every few seconds. For example a simple application may just log
> the stats at the end of a session for retrieval if there is a
> complaint later from the user.

I don't fully agree. I think the simple app will no use stats at all; 
and once it gets a little more advanced it will be very simple for the 
app developer to use setTimeout to get stats at a regular frequency and 
do averaging and so on.

Of course I have nothing against us defining many more metrics, but my 
caution is that it will take use time to agree on what is needed and to 
get it specced up and implemented - while perhaps snapshots would be 
sufficient.

Br,
Stefan

>
> Regards Andy
>
>> -----Original Message----- From: Stefan Hakansson LK
>> [mailto:stefan.lk.hakansson@ericsson.com] Sent: 17 September 2012
>> 22:47 To: public-webrtc@w3.org Subject: Re: Stats interface - Some
>> comments on specific stats
>>
>> FWIW,
>>
>> when we've been working on stats, we've concluded that a simple
>> and often good enough strategy is to just report a snapshot. The
>> application can use several snapshots to get an estimate of
>> averages and so on.
>>
>> The risk of adding stuff is that it pretty quickly grows. Once you
>> add average, someone will be wanting min, max, variance, 95th
>> percentile, ...; or that the codec operated in mode X for the 37.6
>> first percent of the period and then in mode Y for the next 13
>> percent and so on.
>>
>> Stefan
>>
>>
>> On 09/17/2012 11:35 PM, Hutton, Andrew wrote:
>>> See below.
>>>
>>> Andy
>>>
>>>> -----Original Message----- From: Harald Alvestrand
>>>> [mailto:harald@alvestrand.no] Sent: 17 September 2012 19:13
>>>>
>>>> On 09/17/2012 10:05 AM, Hutton, Andrew wrote:
>>>>> Hi Harald,
>>>>>
>>>>> Some comments/questions on the proposal regarding.
>>>>>
>>>>> 1) My understanding of the spec is that the application is in
>>>>> full
>>>> control of when to start/stop reporting, allowing the
>>>> application to collect periodic reports or for the complete
>>>> session. Can you
>> confirm
>>>> that the stats can be retrieved at the time the PeerConnection
>>>> ends. Yes, that is my intention.
>>>>>
>>>>> 2) RTT should be the average round trip time over the
>>>>> reporting
>>>> period can you confirm that this is the case. I don't think
>>>> this is right, since when RTT changes over the course
>> of
>>>> the call, you often want the current estimate, not the estimate
>>>> of
>> 10
>>>> minutes ago. The RTT estimate should be the current value of
>>>> the
>> metric
>>>> defined in the relevant RFC.
>>>
>>> [AndyH] - Understood so maybe we need both. If the application
>>> is
>> gathering and logging stats at the end of session then it would
>> not want just the last RTT but an average for the session.
>>>
>>>>>
>>>>> 3) The number of Silence suppressions in the RTP stream in a
>>>> reporting period need to be included. What's a silence
>>>> suppression, and how do we count them?
>>>
>>> [AndyH] We need an indication how many periods of silence
>>> suppression
>> there has been during the session. How this is counted I
>> understand depends on the codec in use. For some codec's probably a
>> simply count of the RTP packets received with the marker bit set
>> would be ok.
>>>
>>>>>
>>>>> 4) "Jitter" implies maximum jitter in the reporting period,
>>>>> is this
>>>> correct? Again, I think this is the current value of the
>>>> relevant metric. If
>> we
>>>> want a max value, it's best to define a separate metric for
>>>> this.
>>>
>>> [AndyH] Probably we need something more than just the current
>>> value
>> again for the case when an application just logs stats for the
>> whole session when it ends.
>>>
>>>>>
>>>>>
>>>>> Regards Andy
>>>>>
>>>>>
>>>>>> -----Original Message----- From: Harald Alvestrand
>>>>>> [mailto:harald@alvestrand.no] Sent: 02 September 2012
>>>>>> 08:45 To: public-webrtc@w3.org Subject: Re: Stats interface
>>>>>> - modelling on IndexedDB API?
>>>>>>
>>>>>> Attaching the latest proposal after the changes.
>>>>>>
>>>>>> On 08/30/2012 01:03 PM, Stefan Hakansson LK wrote:
>>>>>>> On 08/30/2012 12:53 PM, Harald Alvestrand wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> when implementing the Stats interface, I've concluded
>>>>>>>> that it's
>>>> not
>>>>>>>> quite trivial to do it the way I'd written it up, due
>>>>>>>> to the way
>>>>>> WebKit
>>>>>>>> hangs together.
>>>>>>>>
>>>>>>>> Would anyone mind terribly if I changed it around to do
>>>>>>>> it the
>> way
>>>>>> the
>>>>>>>> IndexedDB API does it?
>>>>>>>>
>>>>>>>> Basically, it seems to be:
>>>>>>>>
>>>>>>>> - Request returns a "request object" with a status and
>>>>>>>> a result - When the data is ready, it fires a "success"
>>>>>>>> event at the
>>>> request
>>>>>>>> object - The caller can then read the data out from the
>>>>>>>> request object
>>>>>>> I think the new approach you propose is better than the
>>>>>>> old one.
>> It
>>>>>>> aligns with e.g. IndexDB and FileReader.
>>>>>>>
>>>>>>>> http://www.w3.org/TR/IndexedDB/#idl-def-IDBRequest
>>>>>>>>
>>>>>>>> Seems a bit easier to get threaded through WebKit than
>>>>>>>> the
>>>> "simpler"
>>>>>>>> method of "just" returning a complex structure in a
>>>>>>>> callback.
>>>>>>>>
>>>>>>>> Harald
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>
>>>
>>
>

Received on Wednesday, 19 September 2012 13:09:17 UTC