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

So it is an implementation problem, not a spec problem.

SCTP allows to signal back the `a_rwnd` in tha `SACK` feedback message:
```
   Each SACK an endpoint receives contains an a_rwnd value.  This value
   represents the amount of buffer space the data receiver, at the time
   of transmitting the SACK, has left of its total receive buffer space
   (as specified in the INIT/INIT ACK).  Using a_rwnd, Cumulative TSN
   Ack, and Gap Ack Blocks, the data sender can develop a representation
   of the peer's receive buffer space.

```
and

```
      As DATA chunks are delivered to the ULP and released from the
      receive buffers, increment a_rwnd by the number of bytes delivered
      to the upper layer.  This is, in effect, opening up rwnd on the
      data sender and allowing it to send more data.  The data receiver
      SHOULD NOT increment a_rwnd unless it has released bytes from its
      receive buffer.  For example, if the receiver is holding
      fragmented DATA chunks in a reassembly queue, it should not
      increment a_rwnd.
```
The issue is that we are considering `ULP` to be the datachannel protocol, and not the js application. If the `a_rwnd` is not decremented when the data chunk are delivered to the datachannel layer for reassembling, but when the event is actually deliver to the js application, we have the back-pressure mechanism that will solve the issue you are describing.

This however imposes a hard limit of 4GB of the amount of buffer that can be "buffered" by the browser (and on individual message length). I think that is reasonable, as to be able to handle messages bigger than that we should allow a more fine grained API to be able to deliver partial data to the js layer of each message as the sctp data chunks are received (maybe with a bit of buffering for ordering). 

-- 
GitHub Notification of comment by murillo128
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2086#issuecomment-457719660 using your GitHub account

Received on Friday, 25 January 2019 20:39:29 UTC