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 12:59:21 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-458121539-1548680361-sysbot+gh@w3.org>
@henbos 

> As I understand it, it is impossible not to read from a stream under normal conditions. As soon as the message has arrived [...]

Let's stop right there. With the proposed change, the message (of size M) will never arrive if M is greater W because of...

> [...] at this point, the receive buffer of the underlying data channel has not been decreased for rawData [...]

A suitable comparison would be a TCP socket with a receive buffer W where one is only peeking (!) for data of size M. This will stall the TCP connection if M > W.

@murillo128 

> [...] 1), 2) and 3). Can we agree on this?

1) is indeed what this was originally about but **the proposed change** would result in 2) and 3) becoming a problem in the first place. 2) and 3) would never happen with the current specification.

> Also, shouldn't 3) be solved by correctly negotiating the max-message-size in the SDP O/A ?

The receive buffer has nothing to do and should never impact the maximum message size (important: **it would** with the proposed change here which is why I'm still arguing!). For example, Firefox uses a buffer of 1 MiB but can receive messages up to 2 GiB. It takes the messages out of the SCTP receive buffer and adds it to a separate reassembly buffer on the channel instance. However, there is no flow control signal because if that would get fed back to the receive buffer, 2) and 3) would suddenly become an issue.

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

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