WebRTC data channel: Optimum message size (#5)

Feb. 5, 2015

This article is the fifth in a series on the topic of the WebRTC data channel. All posts are based on a talk our Chief Architect, Svetlin Mladenov, delivered during the WebRTC conference expo Paris 2014. The accompanying slides are available here and the entire lecture itself can be seen on our YouTube channel.

[Go to Post #1: WebRTC Data Channel: An Overview]


Let’s turn our attention now to the problem of message size. If an application (imagine a chat app) sends small (less than 8 Kbytes) amounts of data only rarely, then the message size does not matter. But what if an application wants to send large amounts of data as quickly as possible (imagine a file-sharing app)? Then one might think that the whole file could be sent at once. Well, this is not going to work due to the following bugs and incompatibilities:

Browser message-size limitations

Chrome cannot send a message larger than 64 Kbytes to another Chrome instance because it gets fragmented into chunks of 64 Kbytes (or less). This is, as previously stated, a violation of the message-oriented principle and is a behavior one cannot rely on.

Chrome cannot send a message larger than 64 Kbytes to Firefox. The message is not fragmented but rather an error is reported.

Firefox cannot send a message larger than 16 Kbytes to Chrome. I don’t know the reason why.

Firefox can send to Firefox messages even larger than 64Kbytes. But this cannot compensate for all the issues above.

So obviously there are a lot of browser incompatibilities and bugs still not resolved. But what is the message size that allows for the highest throughput? On the plot below you can see how the maximum achieved throughput changes as a function of the message size. The two Webrtc Instances, used for the benchmark, operate on the same host and the traffic goes through localhost.

You can see how the blue line that represents Chrome to Chrome communication is quite choppy. It goes up as the size increases and then sharply down (at around a message size of 32 Kbytes) and then back up. The same applies to Chrome sending to Firefox.

Firefox sending to Firefox is an interesting case because the line stays almost flat after you go above 4 Kbytes. In general, Firefox performance and behavior tends to be very stable while Chrome is all over the place which makes it hard to benchmark.

Firefox sending to Chrome (the green line) is a very strange case because it turns out that it is faster to send to Chrome than it is to send to Firefox.

All In all, the takeaway is that a 16 Kbyte message size is the one allowing for the highest throughput, while also being the most portable one. By the way, in some WebRTC tutorials and literature, the authors recommend using 16 Kbytes but they don’t tell you why. Well now you know.

[Go to Post #6: WebRTC bufferedAmount: Sending large amounts of data as quickly as possible]

Author: Svetlin Mladenov, Chief Architect