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: Mon, 28 Jan 2019 17:13:23 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-458218755-1548695602-sysbot+gh@w3.org>
> Those SCTP chunks data retransmissions will use bandwidth, that won't be available for audio and video. Note that audio/video may be hardware accelerated and not affected by the js loop at all.

Ah, I misread your comment. That is a different story though. We have the competition discussion longer than I've been participating and I doubt it's going to make much of a difference if we intentionally drop packets because the event loop queue is already overburdened. The browser will likely have different issues once it reaches that point.

> I am speaking about receiving data, not sure how the .send call is involved.

`.send` raises an exception if one tries to send a message larger than the other peer supports.

> And I was referring that without a new API we will be in this situation anyway.

What situation are we in with the current API?
Can spontaneously deadlock? No.
Can go OOM? Perhaps in dire circumstances. I wouldn't judge browsers killing data channels or even peer connections that go insane with memory usage as long as it's documented.

> Maybe the sctp transmission will not be halted, but the browser will die when having reserved several GBs on intermediary buffers. So yes, I prefer the sctp spontaneous deadlock (Note: I am speaking without an API change).

Then let's agree that we will not agree on this.

-- 
GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-458218755 using your GitHub account
Received on Monday, 28 January 2019 17:13:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 June 2019 15:32:54 UTC