RE: Stats interface - Some comments on specific stats

Hi Stefan,

Ok having thought about your response and consulted some colleagues I think the snapshot will suffice at present. 

Regards
Andy



> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: 19 September 2012 14:09
> To: Hutton, Andrew
> Cc: public-webrtc@w3.org
> Subject: 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 18:41:47 UTC