[rtcweb] SCTP for data channels in rtcweb

Randell Jesup <randell-ietf@jesup.org> Thu, 22 September 2011 15:28 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2C0D121F8BB9 for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 08:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id THq4cTgC2BWX for <rtcweb@ietfa.amsl.com>; Thu, 22 Sep 2011 08:28:48 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com []) by ietfa.amsl.com (Postfix) with ESMTP id 76D3321F8BB2 for <rtcweb@ietf.org>; Thu, 22 Sep 2011 08:28:47 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([] helo=[]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R6lF3-0004An-EV; Thu, 22 Sep 2011 10:31:14 -0500
Message-ID: <4E7B53F0.6000807@jesup.org>
Date: Thu, 22 Sep 2011 11:27:44 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com> <4E776739.4010609@ericsson.com> <4E77949B.4010603@alvestrand.no> <4E78A4FB.1050504@ericsson.com> <4E79AC33.4000900@alvestrand.no> <0075AB47-3DFF-4000-9057-CA0628DF711A@csperkins.org> <05D1C2F6-96C3-44E3-9FC2-AD2C893C9FC6@acmepacket.com> <4E7AE975.1010105@jesup.org>
In-Reply-To: <4E7AE975.1010105@jesup.org>
Content-Type: multipart/alternative; boundary="------------080306080700000201090602"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
Subject: [rtcweb] SCTP for data channels in rtcweb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Sep 2011 15:28:49 -0000

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
    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