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: Wed, 30 Jan 2019 22:39:32 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-459138874-1548887971-sysbot+gh@w3.org>

> If stream schedulers like a round robin scheduler (SCTP_SS_RR) with interleaving enabled is used we could prevent starvation too?

That is my understanding of it. :slightly_smiling_face:

To your proposal: 

#### Receiver side (flow control signal)

If `[[MessageBuffer]]` is lazily allocated then this might be feasible unless I'm missing something. However, it does require that the sending peer actually obeys `max-message-size` as designated by the receiving peer (I know a popular browser that still doesn't \*cough cough\*.), so backwards compatibility is something that would need to be discussed.

#### Sender side (stream/channel monopolisation)

I don't think this needs to be addressed: Analogous to having a separate message receive buffer on each channel, an implementation can have a message send buffer for each channel and do round-robin scheduling of different channel's chunks when putting them into the SCTP send buffer. [Firefox does exactly that](https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/netwerk/sctp/datachannel/DataChannel.cpp#1261). It doesn't fix it completely since whoever comes first still initially fills the send buffer but as soon as a little bit of space becomes available, you're good. And sure, you would still eventually need to throw `OperationError` if the accumulated buffer sizes are becoming an issue but my understanding is that this is a last resort mechanism in case an application ignores *unacceptably high* `bufferedAmount` values (I'll come back to the definition of *unacceptably high* later).

Furthermore, the concrete proposal seems a bit brittle to me, especially when it comes to string messages. Determining the byte length of a string message would be easy to get wrong. It would also be a late API change and (hopefully) obsolete with the streams extension.

This is more of a side note: Adding an attribute to determine the total available buffer space is probably cheap and would be very helpful to determine what a *unacceptably high* is. At the moment, the application has to guess and trigger an exception to determine it.

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-459138874 using your GitHub account
Received on Wednesday, 30 January 2019 22:39:34 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:46 UTC