[rtcweb] Data channel setup and signalling

[Randell Jesup <[e-mail]>]

The signalling discussion and how it touched on data channels got me 
thinking.

One open issue is how we define data channels, both in the "internal" 
case (no interop) and the federated case (which may have the same JS app 
or different ones at either end).

One solution is that all data channels are defined as m= lines.  They 
could be generic "m=data", or they could specify the data to be passed 
in the m= line.  For "public" message structures that might be used by 
different applications (an IM protocol, for example), one would specify 
that in some manner in the media description (perhaps via a MIME type).  
This also implies that any addition or removal (or change to) a data 
channel requires a full replacement OFFER and ANSWER.  If we stick with 
the SDP requirement about never removing m= lines, then the OFFER size 
may become unbounded.

The other option is to have (some) data channels be separate from media, 
in particular app-specific anonymous data channels.  There's no 
requirement for describing the channels if they're private to the app, 
at least to the first approximation.  An app could pre-define data 
channel 3 as a private message structure for game map updates, so long 
as it knows its talking to itself.

This has advantages in setup time, especially if the data channels are 
dynamic and invoked via another data channel, since there doesn't have 
to be a full offer-answer including the media channels.  You just need 
to make sure the two sides agree on the data to be exchanged and that 
they listen before receiving data.  It has a minor advantage in reducing 
the amount of information leakage to the server about the creation and 
types of streams (and potentially significant metadata about them).


A use-case would be a background http proxy-server during chat.  If you 
have to re-OFFER for each data channel that comes and goes to transfer a 
resource, it will both swamp the server and be slow (due to the triangle 
signalling).  If instead the application can open a single control data 
channel, and invoke transfers over it, the application can efficiently 
transfer a high number of URIs.  Are there other ways to do this without 
re-OFFERing constantly?  yes.  But they generally involve building 
protocols on top of an array of long-lasting generic connections.

For example, the control data channel might pass messages (directly 
browser-to-browser) like
{
    id: 1,
    command: "GET",
    URI: "blah/foo/bar",
    channel: 5,
}
with an answer:
{
    id: 1,
    result: "ok",
    size: 1234,
}
followed by transfer of the URI on data channel 5.  (Note: in this I'm 
assuming an API that lets the app open a specific data channel of the 
peer connection.)

Now, this is contrived, though plausible.  You could pre-open a bunch of 
idle data connections and then re-use them as needed.  The 
counter-argument is that one could write a connection-server library 
that abstracts a bunch of pre-opened data channels into an API for the 
app that works like I described above, though it may require more 
housekeeping and larger fixed resource usage.


So.....

Is it worthwhile to consider interfaces/APIs whereby an application 
could directly open data channels with no re-OFFER and implement a 
control protocol similar to the one I described?  Are there other 
use-cases for high-volume data channel create/removal, or where data 
channel latency creation is critical? (my usecase is a little contrived 
since I'm falling asleep a the keyboard.)

-- 
Randell Jesup
[e-mail]