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 16:20:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-458197354-1548692403-sysbot+gh@w3.org>

> What prevents Firefox for declaring a 2GiB buffer size on the first place?

It would be an abuse of the receive buffer to work around an API issue. And it would break once someone activates ndata (which is a spec requirement). Needless to say that transport protocol implementations usually allocate the buffer at once... I think you can imagine what would happen. To quote RFC 4960:

>   Advertised Receiver Window Credit (a_rwnd): 32 bits (unsigned
>   integer)
>   This value represents the **dedicated buffer space**, in number of
>   bytes, the sender of the INIT has **reserved** in association with
>   this window.  During the life of the association, this buffer
>   space SHOULD NOT be lessened (i.e., dedicated buffers taken away
>   from this association); however, an endpoint MAY change the value
>   of a_rwnd it sends in SACK chunks.

Also, let's discuss stream API things in a separate issue.



> If you empty the receive buffer and put it in a temporary message buffer then you can receive messages larger than the receive buffer, but having another buffer does not solve the congestion control problem.

It doesn't solve the problem. I just wanted to clarify that `receive buffer size != maximum message size` by an example.

> Eventually, the temporary message buffer will fill up and then either 1) you stop emptying the receive buffer to get congestion control to kick in, which is a variety of the existing proposal, or you 2) create more message buffers, in which case we have the same problem that we do now (it's just that the buffer is stored in "message buffers" instead of in in-queue PostTasks).

We can't do option 1) because as explained above (which is why Firefox doesn't). It would just expand the time period/message size but the issue would still occur eventually. 2) is, as you already said, not useful.

> If we are CPU-bound we have to have some sort of congestion control. Blocking messages from arriving sounds like a less severe problem than resource exhaustion.

Sure, but the current proposal has a much more severe effect than it's sole intention to *block individual messages* as I explained above.

Let's please call this *flow control* and not *congestion control*. :slightly_smiling_face: *Congestion control* is a different mechanism.


So, here's a suggestion what *could* be done which wouldn't result in all kinds of unwanted side effects: Don't feed decrypted packets from the DTLS stack to the SCTP stack when the event loop queue is congested. They will eventually be retransmitted if it's a reliable channel.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:10 UTC