webrtc/RTCDataChannel-send-close.html is buffering a lot of data channel data but expects to not overflow the buffer

[youennf]

The above test is doing:

while(sentSize < 20 * 1024 * 1024) {
        channel1.send(sendData);
        sentSize += sendDataLength;
}

The test is then expecting that the channel is not firing an OperationError, which is allowed as per https://w3c.github.io/webrtc-pc/#datachannel-send step 6.

Safari is firing this error event, while Chrome and Firefox are not doing so.
If reducing the number of send calls to 16 * 1024 * 1024, the test is passing locally in Safari.

The goal of the test is ensuring that closing the channel will still make sure that the buffered messages are sent. The buffering is triggered by the congestion window size, which is hit in Safari largely before 16 * 1024 * 1024.

The 20 * 1024 * 1024 limit was added in 131d56a, and seems somehow arbitrary.

@guidou , @jan-ivar , do you have any thoughts on why Chrome and Firefox do not end-up in hitting the max buffer size which Safari is?

[guidou]

cc @henbos

[alvestrand]

The DCSCTP default send buffer size is 2 Mbytes (I think it's bytes). The sentSize goes up to 20 Mbytes. But there may be more queues.
@boivie might know more.

[alvestrand]

https://wpt.fyi/results/webrtc/RTCDataChannel-send-close-array-buffer.window.html?label=master&label=experimental&aligned&view=interop&q=label%3Ainterop-2026-webrtc

[youennf]

Looking at chromium code, send can throw if too much data is sent.
In the test, chrome will throw but not safari.
That probably explains the difference of behaviour.
I prefer Chrome approach as it allows the web site to recover more easily.

[alvestrand]

I think this test is not correct for the case where the buffer doesn't throw send() on overflow.

This is the code from webrtc/RTCDataChannel-send-close-helper.js

      try {
         while (sentSize < 20 * 1024 * 1024) {
           channel1.send(sendData);
           sentSize += sendDataLength;
         }
       } catch (error) {
         assert_true(error instanceof DOMException);
         assert_equals(error.name, 'OperationError');
       }
       channel1.onerror = event => {
         assert_unreached(
             `channel1 must not dispatch error events: ${event.error}.`);
       };

I think there should be an assert_precondition after the while loop - "if we get here, the buffer doesn't fill up".

[youennf]

Would be interesting to know whether Firefox is throwing synchronously in case too much data is being buffered.

[lgrahl]

Would be interesting to know whether Firefox is throwing synchronously in case too much data is being buffered.

IIRC at least the usrsctp-backed variant in Firefox has two layers of buffers with the one above usrsctp being (virtually) unbounded.

[jesup]

usrsctp-based DataChannels in firefox was purposely designed to let you do things like transfer a CD ISO image as a blob; in fact I showed that off at IIRC the Atlanta IETF meeting (where we were hotly debating VP8 vs H.264); this was one of the original design criteria - avoid arbitrary limits