Why is WebRTC Datachannel's buffer threshold 8KB?

[Nithyesh Sankar]

I have been trying to understand how WebRTC's data channel works and I found this sample to be very helpful.

The example generates a random string of 16KB and transmits it. However, the data channel's buffered amount is constantly checked. If more than 8KB is buffered, we wait till the buffered amount goes lower than 8KB(refer).

Is there any specific reason for this behavior? I have read elsewhere that the data channel can buffer up to 16MB of data. If that is the case, why is the buffered amount not allowed to exceed beyond 8KB?

[Nils Ohlmeier]

On Apr 26, 2017, at 23:59, Nithyesh Sankar <klas...@gmail.com> wrote:

The example generates a random string of 16KB and transmits it. However, the data channel's buffered amount is constantly checked. If more than 8KB is buffered, we wait till the buffered amount goes lower than 8KB(refer). 

Is there any specific reason for this behavior? I have read elsewhere that the data channel can buffer up to 16MB of data. If that is the case, why is the buffered amount not allowed to exceed beyond 8KB?

My guess is the example hasn’t been updated to utilize https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel/bufferedAmountLowThreshold

Best

  Nils

[Taylor Brandstetter]

This example actually does; it works both with and without support of bufferedAmountLowThreshold, using it if supported by the browser (which should always be true now).

I think the question was more "why is it using a threshold of only 8KB, when the max buffer size is 16MB"? And I don't know; for things like file transfer, it makes more sense to use a larger buffer size, to ensure that the SCTP thread is always busy. So this may have just been an arbitrary choice for example purposes.

I have a question of my own: does the standard guarantee anything about a data channel's max buffer size? I couldn't find anything. If there's no guarantee, how is an application expected to avoid filling the buffer and causing the channel to be closed?

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4EC78AEC-1ECA-4D1F-9BB9-0B10F65C6E43%40mozilla.com.

For more options, visit https://groups.google.com/d/optout.

[Iñaki Baz Castillo]

2017-04-28 1:01 GMT+02:00 'Taylor Brandstetter' via discuss-webrtc
<discuss...@googlegroups.com>:

> I have a question of my own: does the standard guarantee anything about a
> data channel's max buffer size? I couldn't find anything. If there's no
> guarantee, how is an application expected to avoid filling the buffer and
> causing the channel to be closed?

Exactly. good question.




--
Iñaki Baz Castillo
<i...@aliax.net>

[Michael Tüxen]

Why is the channel being closed if you filled up the send buffer?
Can't you indicated that the send call failed due to a full buffer, but
keep the channel up? This is how you would do this on a non-blocking socket...

Best regards
Michael

>
>
>
>
> --
> Iñaki Baz Castillo
> <i...@aliax.net>
>

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfn9OTLXJDzcZ8bzC5sG6ak%3DZT82cp2PpK1YqKMNKjx7mw%40mail.gmail.com.

[Taylor Brandstetter]

I honestly don't know why it works this way. The WebRTC DataChannel API was meant to be as similar to the WebSocket API as possible, and WebSockets do this as well: "if the data cannot be sent, e.g. because it would need to be buffered but the buffer is full, the user agent must close the WebSocket connection with prejudice."

I found one explanation for why WebSockets do this. Paraphrasing: "Application developers aren't likely to check for errors, so if we throw an exception or return false, the error might be ignored, causing a dropped message and loss of data integrity. So we'll just make the buffer really large, to reduce the amount of intermittent errors, and make it fail hard when the buffer does fill up."

I don't agree with this, personally. If a program calls "send" on a non-blocking socket and doesn't check the return value, the blame is on the programmer. So I don't see why JS is any different. And also, making the errors less frequent makes it more likely that an application developer won't notice they have a problem.

So... Maybe we could change this for WebRTC DataChannels? They already have notable differences from WebSockets, so it's not as if we have a hard constraint to keep them the same. Also, part of the reasoning doesn't quite apply: "[The WebSocket closure] seems more likely to get testing since TCP connections do drop at times." SCTP associations won't typically drop, because the application would have done an ICE restart before that happens.

On Sat, Apr 29, 2017 at 9:18 AM, 'Michael Tüxen' via discuss-webrtc <discuss...@googlegroups.com> wrote:

> On 29. Apr 2017, at 16:57, Iñaki Baz Castillo <i...@aliax.net> wrote:
>
> 2017-04-28 1:01 GMT+02:00 'Taylor Brandstetter' via discuss-webrtc

> <discuss-webrtc@googlegroups.com>:

>> I have a question of my own: does the standard guarantee anything about a
>> data channel's max buffer size? I couldn't find anything. If there's no
>> guarantee, how is an application expected to avoid filling the buffer and
>> causing the channel to be closed?
>
> Exactly. good question.

Why is the channel being closed if you filled up the send buffer?
Can't you indicated that the send call failed due to a full buffer, but
keep the channel up? This is how you would do this on a non-blocking socket...

Best regards
Michael

>
>
>
>
> --
> Iñaki Baz Castillo
> <i...@aliax.net>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CALiegfn9OTLXJDzcZ8bzC5sG6ak%3DZT82cp2PpK1YqKMNKjx7mw%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/30E3EAB4-0040-478A-95F1-1B78F3933EEE%40googlemail.com.