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: Sat, 26 Jan 2019 22:14:18 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-457870428-1548540857-sysbot+gh@w3.org>
> let's put it in a different view. Taking into account just one single datachannel will the proposed solution solve the issue?

No, not with the message-based API that we have. My second example in https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457827612 (2 MiB message, 1 MiB receive buffer) would still apply for just a single channel.

> Also, does the problem about multichannel buffering still exist without taking into account the event loop queueing issue?

Yes. We can pause receiving on the whole association (read: all streams simultaneously) which lets the flow control kick in. We cannot selectively pause receiving on individual streams. It's either receiving data on all streams or (eventually) receiving no data.

> you may have a solution for not problems simultaneously, but it also requires a change in w3c apis and ietf specs.

Yeah, there's no easy fix. It's just how it is. :woman_shrugging: @jan-ivar and I briefly touched this topic as part of the streams extension. My idea to ~~solve~~ work around this goes into the direction of kindly asking the sender to pause/continue sending data on a particular stream by using a special PPID.

> To solve this issue we only need one line in the spec without api change.

Unfortunately not.


-- 
GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457870428 using your GitHub account
Received on Saturday, 26 January 2019 22:14:20 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 October 2019 15:15:01 UTC