1561923 - Remove expired WebRTC telemetry

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Dan Minor [:dminor]]

I have a spreadsheet here that covers both media and webrtc probes: https://docs.google.com/spreadsheets/d/1Oh_MYGTGG0Vq5N8z8FAzX46P3SWMwDU3Rm-EFGu80yg/edit#gid=905776447

Here is a list of expired probes that seem webrtc related:

• WEBRTC_ICE_OFFERER_ABORT_TIME 60 The length of time (in milliseconds) it took for the offerer to abort ICE due to some external factor (eg; PeerConnection torn down). Does not count cases where StartChecks() was never called.
• WEBRTC_ICE_ANSWERER_FAILURE_TIME 60 The length of time (in milliseconds) it took for the answerer to complete ICE, given that it failed. Does not count cases where StartChecks() was never called.
• WEBRTC_ICE_OFFERER_FAILURE_TIME 60 The length of time (in milliseconds) it took for the offerer to complete ICE, given that it failed. Does not count cases where StartChecks() was never called.
• WEBRTC_ICE_OFFERER_SUCCESS_TIME 60 The length of time (in milliseconds) it took for the offerer to complete ICE, given that ICE succeeded.
• WEBRTC_DTLS_CLIENT_SUCCESS_TIME 60 The length of time (in milliseconds) it took for a client DTLS handshake to complete, given that DTLS succeeded.
• WEBRTC_DTLS_SERVER_FAILURE_TIME 60 The length of time (in milliseconds) it took for a server DTLS handshake to complete, given that it failed.
• WEBRTC_ICE_ANSWERER_ABORT_TIME 60 The length of time (in milliseconds) it took for the answerer to abort ICE due to some external factor (eg; PeerConnection torn down). Does not count cases where StartChecks() was never called.
• WEBRTC_DTLS_SERVER_SUCCESS_TIME 60 The length of time (in milliseconds) it took for a server DTLS handshake to complete, given that DTLS succeeded.
• WEBRTC_DTLS_CLIENT_FAILURE_TIME 60 The length of time (in milliseconds) it took for a client DTLS handshake to complete, given that it failed.
• WEBRTC_DTLS_SERVER_ABORT_TIME 60 The length of time (in milliseconds) it took for a server DTLS handshake to be aborted due to some external factor (eg; PeerConnection torn down).
• WEBRTC_ICE_NR_ICE_GATHER_TIME_IMMEDIATE_SUCCESS 60 The length of time (in milliseconds) it took to call nr_ice_gather, given that gathering succeeded immediately during the call.
• WEBRTC_ICE_NR_ICE_GATHER_TIME_IMMEDIATE_FAILURE 60 The length of time (in milliseconds) it took to call nr_ice_gather, given that gathering failed immediately during the call.
• WEBRTC_ICE_ANSWERER_SUCCESS_TIME 60 The length of time (in milliseconds) it took for the answerer to complete ICE, given that ICE succeeded.
• WEBRTC_ICE_NR_ICE_GATHER_TIME 60 The length of time (in milliseconds) it took to call nr_ice_gather, given that gathering did not succeed/fail immediately during the call.
• MEDIACACHESTREAM_LENGTH_KB 60 MediaCacheStream stream length size in KB; Either known size from the HTTP header if available, or otherwise the size actually downloaded. Recorded at every MediaCacheStream destruction.
• WEBRTC_DTLS_CLIENT_ABORT_TIME 60 The length of time (in milliseconds) it took for a client DTLS handshake to be aborted due to some external factor (eg; PeerConnection torn down).
• WEBRTC_GET_USER_MEDIA_SECURE_ORIGIN 60 Origins for getUserMedia calls (0=other, 1=HTTPS, 2=file, 3=app, 4=localhost, 5=loop, 6=privileged)
• WEBRTC_ICE_ON_TIME_TRICKLE_ARRIVAL_TIME 62 The length of time (in milliseconds) that a trickle candidate took to arrive after the start of ICE, given that it arrived when ICE was not in a failure state (ie; a candidate that we could do something with, hence 'on time')
• WEBRTC_ICE_FINAL_CONNECTION_STATE 62 The ICE connection state when the PC was closed
• WEBRTC_NICER_TURN_403S 62 The count of TURN 403 (Forbidden) responses to CreatePermission or ChannelBind requests. This indicates that the TURN server is refusing the request for an IP address or IP address/port combination, likely due to administrative restrictions. For more info on ICE, see https://tools.ietf.org/html/rfc5245 For more info on STUN, see https://tools.ietf.org/html/rfc5389 For more info on TURN, see https://tools.ietf.org/html/rfc5766
• WEBRTC_ICE_LATE_TRICKLE_ARRIVAL_TIME 62 The length of time (in milliseconds) that a trickle candidate took to arrive after the start of ICE, given that it arrived after ICE failed.
• WEBRTC_ICE_ADD_CANDIDATE_ERRORS_GIVEN_SUCCESS 62 The number of times AddIceCandidate failed on a given PeerConnection, given that ICE succeeded.
• WEBRTC_RTCP_MUX 62 Was RTCP-MUX negotiated for a track
• WEBRTC_NICER_TURN_438S 62 The count of TURN 438 (Stale Nonce) responses to allocation requests. This can happen during both successful and unsuccessful WebRTC calls. For more info on ICE, see https://tools.ietf.org/html/rfc5245 For more info on STUN, see https://tools.ietf.org/html/rfc5389 For more info on TURN, see https://tools.ietf.org/html/rfc5766
• WEBRTC_STUN_RATE_LIMIT_EXCEEDED_BY_TYPE_GIVEN_SUCCESS 62 For each successful PeerConnection, bit 0 indicates the short-duration rate limit was reached, bit 1 indicates the long-duration rate limit was reached
• WEBRTC_ICE_ADD_CANDIDATE_ERRORS_GIVEN_FAILURE 62 The number of times AddIceCandidate failed on a given PeerConnection, given that ICE failed.
• WEBRTC_NICER_TURN_401S 62 The count of TURN 401 (Unauthorized) responses to allocation requests. Only 401 responses beyond the first, expected 401 are counted. More than one 401 repsonse indicates the client is experiencing difficulty authenticating with the TURN server. This can happen during both successful and unsuccessful WebRTC calls. For more info on ICE, see https://tools.ietf.org/html/rfc5245 For more info on STUN, see https://tools.ietf.org/html/rfc5389 For more info on TURN, see https://tools.ietf.org/html/rfc5766
• WEBRTC_STUN_RATE_LIMIT_EXCEEDED_BY_TYPE_GIVEN_FAILURE 62 For each failed PeerConnection, bit 0 indicates the short-duration rate limit was reached, bit 1 indicates the long-duration rate limit was reached
• WEBRTC_NICER_STUN_RETRANSMITS 62 The count of STUN message retransmissions during a WebRTC call. When sending STUN request messages over UDP, messages may be dropped by the network. Retransmissions are the mechanism used to accomplish reliability of the STUN request/response transaction. This can happen during both successful and unsuccessful WebRTC calls. For more info on ICE, see https://tools.ietf.org/html/rfc5245 For more info on STUN, see https://tools.ietf.org/html/rfc5389 For more info on TURN, see https://tools.ietf.org/html/rfc5766
• WEBRTC_DTLS_CIPHER 66 The DTLS cipher (as integer) negotiated for a RTCPeerConnection. See TransportLayerDtls::RecordCipherTelemetry for the meaning of the values
• WEBRTC_SRTP_CIPHER 67 The SRTP cipher (as label) negotiated for a RTCPeerConnection.
• WEBRTC_DTLS_PROTOCOL_VERSION 68 The DTLS protocol version (as label) negotiated for a RTCPeerConnection.

I think the easiest way ahead is for me to produce a patch to remove all of the expired probes, and we flag anything that should be renewed rather than removed during code review.

Comment 1

[Dan Minor [:dminor]]

Attachment: Bug 1561923 - Remove expired WebRTC telemetry; r=bwc,drno

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/470fee6b6090
Remove expired WebRTC telemetry; r=drno,bwc

Comment 3

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/470fee6b6090