Data Channel multiplexing design choice

[midhul varma]

This is a question regarding a design decision I'm trying to make related to WebRTC's DataChannel functionality.

Lets say I want to build a browser app which allows peers to transfer files to each other. (request response style)

Assume peers send requests for files as single messages on a DataChannel and responses of file data are chunked into multiple DataChannel messages (to avoid monopolization of the SCTP association). Consider the simple case of just 2 peers.

The following design options come to mind:

- Create a single DataChannel between the peers during connection initialization and multiplex all data on it (both request messages and response chunks). Multiplexing logic will have to written in the application.

- Create two DataChannels (on same peer connection) between the peers, one for transporting requests and one for transporting response chunks. Here some sort of multiplexing needs to be implemented for the response data channel, as two files being sent concurrently from the same peer may experience interleaving of chunks and the application needs to know which chunk belongs to which file.

- Create one DataChannel during initialization. This is used to transport request messages. For transferring response file chunks new DataChannels are created on demand for every file i.e. when a peer receives a request for a file it creates a new DataChannel and sends the content chunks on that data channel, closing it after the transfer is complete. Here since files being sent concurrently will be sent on different data channels, there is no need to implement multiplexing logic at all in the application.

Since SCTP anyway multiplexes multiple streams over a single association, re-implementing multiplex logic at the application level doesn't seem right. For this reason the third option looks attractive to me. However I am worried about performance. In particular, what is the overhead associated with creating a DataChannel (on an RTCPeerConnection where offer/answer exchange, ICE checks and all that stuff is already done)? Can I assume a startup delay of 1 RTT? In general, is it a good idea to create DataChannels on-demand like this?

Looking forward to some constructive advice on this issue.

Thanks

Midhul  

[Blake La Pierre]

The third option seems right to me too. One thing to check would be if setting up a data channel requires any kind of pre-negotiation as that could affect the time to first bit versus using an established channel. If the channels can be setup without a round-trip response, then I don't see why you wouldn't want to let something else handle the connection multiplexing. Even if there is a round-trip involved, the simplification in logic that you get might be worth it.

[Taylor Brandstetter]

The third option sounds the best to me. In addition to letting SCTP handle the multiplexing as it was designed to, it has the advantage that when a packet is dropped for one file, it won't block the transmission of the other files (see: https://tools.ietf.org/html/rfc4960#section-1.5.2).

As for the overhead of creating a data channel: even if the data channel is negotiated in-band (leaving `negotiated` set to false in the `RTCDataChannelInit`), the data channel can be used to send immediately after sending the "open" message (see: https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-6). So there are no wasted round trips; the only overhead is an extra message being sent. And if you negotiate the data channel out-of-band—meaning your application decides the IDs, by putting them in the request messages, for example—then there is no overhead at all.

--

---
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/7ef9ab56-3617-449a-b7a3-d5c3261cb536%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Peter Thatcher]

Taylor is right.  There is no reason not to make several data channels.  There is no meaningful overhead with creating one.  And there is no delay between creating one and sending data.  We specifically design it to be like that.  

On the other hand, multiplexing over one data channel forces ordering between different logical streams of messages, which may be undesirable. 

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

[midhul varma]

Thanks for the feedback Blake, Taylor and Peter.

This will hopefully make my implementation a lot easier