RE: Stats interface - Some comments on specific stats

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.

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 08:50:28 UTC