W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

RE: Generalizing the stats hierarchy

From: Matthew Kaufman <matthew.kaufman@skype.net>
Date: Mon, 24 Sep 2012 20:12:13 +0000
To: Eric Rescorla <ekr@rtfm.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <AE1A6B5FD507DC4FB3C5166F3A05A4840E50B64B@TK5EX14MBXC273.redmond.corp.microsoft.com>
You just need Get, Set, and GetNext... and to allocate the appropriate part of the SNMP OID space.

And why JSON when there's all the ASN.1 encodings?

Matthew Kaufman

-----Original Message-----
From: Eric Rescorla [mailto:ekr@rtfm.com] 
Sent: Monday, September 24, 2012 8:13 AM
To: public-webrtc@w3.org
Subject: Generalizing the stats hierarchy

Harald,

In draft-alvestrand-rtcweb-stats-registry-00.txt, you observe that there are times when a single named statistics value actually corresponds to a number of elements and you would like to be able to address them individually. You suggest handling this case with the convention of appending a ".X" to the stat in question, but I think this actually points to the need towards genuinely hierarchical stats.

Consider the case where you want to examine every aspect of ICE, which I think there is general consensus we need. At this point we have the following containment hierarchy:

  - Media Stream  [W3C name: track]
  - Component     [RTP or RTCP]
  - Local candidate
    - State
    - Check history
    - Estimated RTT

This seems pretty deep to represent cleanly in the existing hierarchy but would fit well into a more generic structure.

Here's a strawman to give you an idea of what I have in mind:

- Instead of being just opaque strings, stats identifiers
  should be dot-separated strings, with dots separating
  levels in the hierarchy.

- When registered, each stats identifier must be one of:

  * value -- the value is in the stat itself
  * array -- the stat contains a list of values in an array
    (i.e., [])
  * dictionary -- the stat contains a list of values in a
    dictionary (i.e., {})

- You can call getValue() at any level in the hierarchy
  and what you get depends on the identifier type. You
  can subaddress arrays and dictionaries by including
  the index/key in the identifier (as shown below).


Reworking your ICE example in this fashion would give us something like this:

{ local: { timestamp: 12345, stats: {
         SentPackets: 47,
         SentOctets: 4444,
         ReceivedPackets: 33,
         ReceivedOctets: 2346,
         ICE: [
           {
             State: Succeeded
             Used: True,
             LocalIpAddr: '129.241.1.99',
             RemoteIpAddr:'234.978.4.3'
           },
           {
             LocalIPAddr: '10.0.0.1',
             RemoteIPAddr: '10.0.1.24',
             State: Succeeded
             Used: False
           }
         ]
}}}

ISTM that this places things that naturally go together together, and also makes it easier to build processing engines without a lot of string manipulation.


If I am reading the current API correctly, the only way to actually get at a statistics value is to do .getValue() on an RTCStatsReport.
In this case, the code would then be something like this:

   report.getValue('SentPackets') --> 47
   report.getValue('ICE') -->
         ICE: [
           {
             State: Succeeded
             Used: True,
             LocalIpAddr: '129.241.1.99',
             RemoteIpAddr:'234.978.4.3'
           },
           {
             LocalIPAddr: '10.0.0.1',
             RemoteIPAddr: '10.0.1.24',
             State: Succeeded
             Used: False
           }
         ]


   report.getValue('ICE.0') -->
           {
             State: Succeeded
             Used: True,
             LocalIpAddr: '129.241.1.99',
             RemoteIpAddr:'234.978.4.3'
           }

   report.getValue('ICE.0.State') --> 'Succeeded'

Thoughts?
-Ekr
Received on Tuesday, 25 September 2012 15:09:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 September 2012 15:09:34 GMT