[rtcweb] SCTP for data channels in rtcweb

[Randell Jesup <[e-mail]>]

On 9/22/2011 3:53 AM, Randell Jesup wrote:
> On 9/21/2011 7:45 AM, Hadriel Kaplan wrote:
>> Just to make sure I'm on the same wavelength, you're talking about:
>> 1) Defining PseudoTCP over UDP (a la libnice and jingle) for 
>> stream-oriented reliable data delivery.
>
> I would also consider SCTP-over-UDP in place of PseudoTCP-over-UDP for 
> reliable
> data delivery.  Similar arguments apply as for DCCP (solid 
> specification), and
> in addition the FreeBSD implementation apparently supports 
> SCTP-over-UDP and is
> very portable, so good working code is available to start.  SCTP also 
> has other
> benefits, like optional out-of-order delivery, and a datagram 
> ('message') orientation.

I'm in touch with the SCTP-over-UDP draft authors, and received this:

    so you want a reliable and unreliable datagram service. You can use SCTP for both:
    1. Standard SCTP/UDP for a reliable datagram service.
    2. SCTP/UDP with the PR-SCTP extension and using a policy which doesn't do
        retransmissions. This is also implemented in the FreeBSD implementation
        and the derived ones, like the one for Mac OS X, Userspace and so on.

    There is also an RFC for running DTLS/SCTP which also applies to DTLS/SCTP/UDP
    to secure the traffic. We also have running code for it as you can get a
    patch for OpenSSL from
    http://sctp.fh-muenster.de/dtls-patches.html
    It has been submitted to the OpenSSL maintainers for inclusion in OpenSSL 1.0.1.

    Please let us know if you have any further question.

So, overall this seems *very* promising - both in terms of a single framework to use
for all the data channels (one interface/API, etc), existing congestion control
(unfortunately TCP-like -- loss-based -- but oh well), and a working, open
-over-UDP/-over-DTLS spec and implementation.

I'd still love to tie the congestion control into the unified control we're looking
at for the media streams, but I think we can make this work well even without that.


-- 
Randell Jesup
[e-mail]