- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Jan 2019 22:39:32 +0000
- To: public-webrtc-logs@w3.org
@henbos > 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