Add SCTP association capability stats to getStats()

[JoTurk]

Applications using WebRTC data channels may want to adapt their sending strategy based on negotiated SCTP association capabilities. This is especially true with message interleaving (RFC-8260, currently enabled by default in Firefox).

For example, if SCTP message interleaving is enabled, an application can safely batch larger messages without causing the same send-side head-of-line blocking behavior. If interleaving is not enabled, the application may prefer smaller chunks, different batching thresholds, fewer concurrent large sends, or / and application-level scheduling.

Today this can be observable in browser-to-non-browser cases when the non-browser endpoint exposes SCTP association metadata. For example, At Pion we're adding getStats exposure for negotiated SCTP features including interleaving, partial reliability mode, and zero-checksum send/receive state: pion/webrtc#3424

The problem is with browser-to-browser WebRTC, the web application has no interoperable way to determine whether SCTP message interleaving was negotiated. RTCSctpTransport exposes state, maxMessageSize, and maxChannels, but not SCTP association capabilities such as message interleaving. RTCDataChannelStats just exposes per-channel counters,.

Applications can make adaptive decisions when one side is a non-browser endpoint, but cannot make the same decisions in browser-to-browser deployments.

Proposed addition

Expose SCTP association-level stats, for example extending RTCSctpTransportStats with:

dictionary RTCSctpTransportStats : RTCStats {
  RTCSctpTransportState state;
  boolean messageInterleavingEnabled;
  DOMString partialReliabilityMode;
  boolean zeroChecksumSendingEnabled;
  boolean zeroChecksumReceivingEnabled;
};

[fippo]

We also still have https://w3c.github.io/webrtc-provisional-stats/#RTCSctpTransportStats-dict* which has

dictionary RTCSctpTransportStats : RTCStats {
      DOMString transportId;
      double smoothedRoundTripTime;
      unsigned long congestionWindow;
      unsigned long receiverWindow;
      unsigned long mtu;
      unsigned long unackData;
};

negotiated values seem more like something you don't put in getStats but it is convenient and we have #819 too

[alvestrand]

attention @boivie

[steely-glint]

I'm in favour of adding this info - but I wonder if it wouldn't be better to expose the actual SCTP names rather that an approximate description of what they do. - For example messageInterleavingEnabled might give a misleading impression of the limitations of the actual implementation. Giving the SCTP name forces the developer to look them up and (hopefully) understand what they can and can't do and how they may interact with each other.

Also these capabilities are static (per association). Is there a way to separate them from the more dynamic properties like unAckedData ? - Are they actually properties of the SCTPTransport rather than stats ?

[JoTurk]

@steely-glint I agree that they are conceptually transport properties rather than dynamic stats.

My main reasons for proposing them via getStats is for diagnostics and discovery reason; Many WebRTC debug flows already collect raw getStats() dumps, and many diagnostics tools are third party that only have access to those dumps rather than live PeerConnection objects.

If these stats or capabilities are only exposed as transport properties, each application would need to explicitly read and export them itself, and exposing them through getStats allows generic and pre-exisiting tools to automatically correlate negotiated SCTP capabilities with observed SCTP/data-channel behavior and performance issues, especially when combined with pre-exisiting other stats, for example, message interleaving can become much more relevant under poor bandwidth and high RTT conditions,

[steely-glint]

@JoTurk that makes sense - perhaps putting it in both places would be useful. Stats for diagnosing problems but SCTPTransport so the app can detect the situation and then change behaviour (maybe make a second peer connection to carry small high value messages).