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

> 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 (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 using your GitHub account

Received on Saturday, 26 January 2019 22:14:20 UTC