W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > January 2019

Re: [webrtc-pc] (How) does SCTP handle CPU-bound congestion on JavaScript thread? (#2086)

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Fri, 25 Jan 2019 15:23:29 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-457607907-1548429807-sysbot+gh@w3.org>
This could be a slight improvement for WebSockets but it would not work for SCTP-based data channels. SCTP has only one receive buffer per association. Thus, you would risk that one data channel *filling up* (for example a low priority file transfer or, even worse, a channel that is being completely ignored and never bound by the application) blocks receiving messages from another data channel (for example real-time sensor data).
Furthermore, doing this on a message-based level is insufficient since messages can be of arbitrary size (although Chrome refuses to accept that messages can be larger than 64 KiB :stuck_out_tongue:). If one side sends a 10 MiB message then you still have to buffer 10 MiB. The same applies to 100 MiB, and so on. That breaks the backpressure mechanism.

So, we not only need an API that allows to receive parts of a message (#1732) but also find a solution for the *one receive buffer per association* problem which requires some protocol work. I have some ideas how it could be done by using PPIDs to signal backpressure.

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457607907 using your GitHub account
Received on Friday, 25 January 2019 15:23:31 UTC

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