- From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
- Date: Thu, 06 Jan 2022 02:22:54 +0000
- To: public-webrtc-logs@w3.org
There does seem to be a legitimate need here, but it is not obvious to me how to address this within the WebRTC 1.0 API. It is well documented that the current SCTP congestion control algorithm (New Reno) is problematic in latency sensitive applications. A similar issue has been opened against WebTransport API (BBRv1 or v2 has the same problem): [Issue 365]( https://github.com/w3c/webtransport/issues/365) To get around this problem, cloud-based applications routinely customize SCTP congestion control algorithms to enable scenarios such as cloud gaming (e.g. replacing New Reno with an algorithm such as SCREAM, RFC 8298). However, this only works in scenarios where the data flows from the cloud peer (e.g. the server) to a browser, not in the other direction. Since congestion control operates on an SCTP association, not on an individual data channel, it would not make sense to add parameters to `RTCDataChannelInit`. In ORTC, parameters can be passed to the RTCSctpTransport constructor to enable customization of SCTP congestion control behavior. However, the WebRTC 1.0 API "vends" RTCSctpTransport objects, rather than allowing them to be constructed. Changing the congestion control algorithm on a live SCTP association seems unnecesarily complex, so an `RTCSctpTransport.setParameters()` method doesn't make much sense. -- GitHub Notification of comment by aboba Please view or discuss this issue at https://github.com/w3c/webrtc-extensions/issues/71#issuecomment-1006232585 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 6 January 2022 02:22:56 UTC