W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2018

Re: [webrtc-stats] [DataChannels] Expose bandwidth or congestion window from the SCTP lib

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Tue, 23 Oct 2018 16:10:07 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-432312840-1540311006-sysbot+gh@w3.org>
> > That's a bug.
> AFAIK it's not a bug, since bufferedAmount don't include the sctp buffer.

It is definitely a bug. See the [corresponding spec section](https://w3c.github.io/webrtc-pc/#dom-rtcdatachannel-bufferedamount). The only reason why all implementations are affected by this is because they all use usrsctp which currently does not expose that information.

> Since, we are on the topic of this, what other SCTP stats would applications want to use? also are there any other SCTP metrics that would be interesting for the app

I'm not seeing further items that should be in the stats (there are a couple that could be added to `RTCSctpTransport` at some point, such as MTU, partial delivery point, RT max, RTO initial/min/max, heartbeat interval, ...). Arguably, some of these *could* also be in the stats but I'm not entirely convinced about that so far.

> also interesting but more futuristic, for us at least: maximum size for data payload before packet will be split to 2 (mtu - all the headers calculation)

I believe that should not be in the stats but rather on the `RTCSctpTransport`. Interesting candidates are https://tools.ietf.org/html/rfc6458#section-8.2.1 `sstat_fragmentation_point` and https://tools.ietf.org/html/rfc6458#section-8.2.2 `spinfo_mtu` (I'm not sure what's the difference between those two and would have to ping my fellow SCTP expert for that).

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/377#issuecomment-432312840 using your GitHub account
Received on Tuesday, 23 October 2018 16:10:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:07 UTC