Re: Timestamps in stats

On 01/09/2013 05:04 AM, Cullen Jennings (fluffy) wrote:
> On Jan 8, 2013, at 9:33 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
>
>> On 01/08/2013 04:58 PM, Cullen Jennings (fluffy) wrote:
>>> I don't  think the single timestamp for stats is going to work. Consider a stat that the remote side only provides once every 10 seconds and a local stat that get updated with every packet sent. If someone requested both of these stats, what timestamp would get returned?
>>>
>>> I think the timestamps need to be associated with the stat, not the report.
>> That's why there's a timestamp on each stat group. Remote (RTCP-reported) stats are going to be in different groups from local stats. But when you get a #packets and #bytes from the same end of a connection, they should have the same timestamp.
> That was a bad example on my part. Let me try again. Lets say browser A receives a RTCP packet with a "JB nominal" (section 4.7.7 rfc 3611) value from the remote side a time stamp X, then shortly after that receives from the remote side ( for the same track, SSRC, etc ) a RTC packet with a different time stamp Y and no "JB nominal" value but does have a "round trip delay" as defined in section 4.7.3 of 3611. After both these RTCP reports are received, the JS queries the stats for this track. It seems like these two measurements came from different times yet. (I just picked these two as random examples, I'm not claiming that we need to support either of these but I suspect that we get to a similar issue with ones that we will choose. )
Is that legal in RTCP / RTCP-XR - sending different stats at different 
times, and expecting the receiver to build up a total picture of the 
sender's stats from unsynchronized values?

I don't see any signalling in section 5 of RFC 3611 that indicates how 
one should expect to see these stats grouped, or whether an RTCP message 
is a "full report" or a "partial report", but I've spent very little 
time contemplating XR blocks.

The resulting statistical processing would be painful, but could be done.
>
>>> I'm not seeing how things like all the ICE candidates get reported.
>> Which document are you reading?
> Oh, it's been a week of reading the wrong spec. What should I be reading ?
>
The one attached to "Stats v2 proposal - for Thursday's meeting" - the 
file name is RTCWEBStatsV2.pdf

Look for this:

// Candidates borrow heavily from RFC 5245 ICE terminology.
dictionary Candidate {
IPAddress ipAddress;
int port;
enum {‘udp’, ‘tcp’, ... } transport;
enum {...} type;
int priority;
DOMString componentId;
// RelatedAddr?
// Base?
}

dictionary CandidatePair {
// ICE information from RFC 5245
StatsObjectID localCandidate;
StatsObjectID remoteCandidate;
bool valid;
bool nominated;
enum {‘closed’, ‘trying’, connected’} state;
// Statistics
int packetsSent;
int packetsReceived;
long bytesSent;
long bytesReceived;
}

Received on Wednesday, 9 January 2013 07:45:03 UTC