What is the lifetime of datachannel stats?

[fippo]

https://jsfiddle.net/fippo/gLs015hm/1/
shows that data-channel stats exist before negotiation. In Chromium (and hence probably Safari) and Firefox.

No packets are sent yet stats exist. Why?

(see also #804)

[alvestrand]

Fixing the fiddle to show data-channel stats rather than transport stats, I get:

[{
bytesReceived: 0,
bytesSent: 0,
dataChannelIdentifier: 0,
id: "D2",
label: "getStats",
messagesReceived: 0,
messagesSent: 0,
protocol: "",
state: "connecting",
timestamp: 1743454696985.706,
type: "data-channel"
}]

Note that the label and protocol fields, as well as the state, have values that give some information that might be useful.

[fippo]

Updated above, thank you!

Showing dataChannelIdentifier 0 after negotiation seems risky, the DTLS role can still change after a ICE role conflict?
Firefox showing dataChannelIdentifier: 65535 pre-negotiation... wait, did we not discuss that recently?

[jan-ivar]

Firefox showing dataChannelIdentifier: 65535 pre-negotiation... wait, did we not discuss that recently?

This bug was fixed last week in bug 1981595 (Firefox 143).

Showing dataChannelIdentifier 0 after negotiation seems risky,

I'm not able to reproduce that. But I am seeing some differences with https://jsfiddle.net/jib1/2qk9as1n/

Safari, Chrome, Firefox:

Observations:

1. Only Firefox exposes "data-channel" stats ahead of sLD (after: [null] vs after: [])
2. All browsers expose "data-channel" stats after sLD but with a null dataChannelIdentifier, which might needlessly trip up readers for scant benefit
3. All browsers initialize dataChannelIdentifier on returning to stable
4. The spec seems written to do basic counting at the API level, not the underlying transport level, aligning with Firefox: but this may have been a mistake that didn't anticipate data channels in workers.

Having pc.getStats() thread-hop to every worker to collect counts seems inefficient, especially since this needs to be done whether callers care about these stats or not.

Are other browsers counting at the underlying transport level? I so, I think we're open to redefining this.

There appear to be no WPT tests for this.

[fippo]

I'm not able to reproduce that.

https://jsfiddle.net/fippo/gLs015hm/4/ makes it more obvious.
The problem here is that data channel ids are assigned odd/even depending on the DTLS role (see DCEP) which might change if there is an ICE role conflict. It is likely ok to expose after negotiation at least when a=setup is used.

But the point here is: why was a principle of "no packets no stats" proclaimed for RTP in #619 and is not followed by any browser for data channels?

[jan-ivar]

https://jsfiddle.net/fippo/gLs015hm/4/ makes it more obvious.

Wow that shows all the browsers returning "data-channel" stats objects without a .dataChannelIdentifier member initially. So readers have to contend with partially filled in dictionaries (undefined), null and 0. Not great.

The problem here is that data channel ids are assigned odd/even depending on the DTLS role (see DCEP) which might change if there is an ICE role conflict. It is likely ok to expose after negotiation at least when a=setup is used.

Let's align on exposing after negotiation then (going back to "stable"). This would align with #802 and be more consistent.

This would also let us move counting to the underlying data transport, which would make it simpler to account for data channel activity in workers.

[fippo]

So readers have to contend with partially filled in dictionaries (undefined), null and 0. Not great.

This is WAI, datachannel.id is unset before the DTLS role is determined too and nobody complained about that ever.
But we do have a spec-problem in webrtc-pc... w3c/webrtc-pc#3071

Let's align on exposing after negotiation then (going back to "stable").

For RTP (lets move to #619?) looking whether the transceiver's currentDirection works nicely, I had an implementation along those lines a while back.
For SCTP requiring that the dataChannelIdentifier is set should work with the caveat that negotiated channels show up early.

[alvestrand]

Re thread- hopping: In practice, I believe that the existence and ID of datachannels has to live where the SCTP protocol engine lives. That's one place.
Each worker has to talk to that one place, and stats needs to talk to that one place too.
For stats, there should be no need to talk to the workers.

[jan-ivar]

For SCTP requiring that the dataChannelIdentifier is set should work with the caveat that negotiated channels show up early.

I agree for non-{negotiated: true} data channels obviously, since the dataChannelIdentifier is set going back to "stable".

But https://jsfiddle.net/jib1/2qk9as1n/21/ shows adding {negotiated: true, id: 7} does not expose "data-channel" stats any earlier in Chrome and Safari today. I would not force the Firefox behavior on Chrome and Safari here only in this case, as this seems unnecessarily complicated.

In practice, ... the existence and ID of datachannels has to live where the SCTP protocol engine lives

I'm supportive of this interpretation. We should clarify the spec to say the monitored object for these stats is the underlying data transport and not the RTCDataChannel JS object. This also seems consistent with exposure on going to "stable".

[fippo]

the problem with stable is that https://jsfiddle.net/fippo/gLs015hm/7/ makes objects show up which then get negotiated away and deleted. And on an established datachannel connection that adds audio or video you don't want to suppress the stats during renegotiation.

I'll check why {negotiated: true, id: 7} does not show in Chromium, that seems unexpected.

[fippo]

I'll check why {negotiated: true, id: 7} does not show in Chromium, that seems unexpected.

It does show up if you call getStats a second later suggesting there is a cache invalidation missing. Nice catch!

You are missing an await on the before dumpStats which makes the logging a bit confusing - on my Linux chrome the id log consistently shows up first. And I think browsers are more aligned than we thought.

[henbos]

But the point here is: why was a principle of "no packets no stats" proclaimed for RTP in #619 and is not followed by any browser for data channels?

We have abandoned "no packets no stats" for outbound-rtp where we said we can expose them at "stable" whether or not packets have been sent as this turns out to be useful. For inbound-rtp, we still do "no packets no stats" in order to get consistent stats lifetime whether or not SSRCs have been signalled in the SDP. There we also have the case of early media so it's possible to receive packets before going back to "stable" which means you could have {direction:'recvonly', currentDirection:null} and still have data to monitor.