Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]

Colin Perkins <> Wed, 21 September 2011 12:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02EB021F8B3E for <>; Wed, 21 Sep 2011 05:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.532
X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ctMgtS5YlFtS for <>; Wed, 21 Sep 2011 05:07:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D250921F8AFD for <>; Wed, 21 Sep 2011 05:07:22 -0700 (PDT)
Received: from ([]) by with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6Lcc-00041Q-b9; Wed, 21 Sep 2011 12:09:50 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: Colin Perkins <>
In-Reply-To: <>
Date: Wed, 21 Sep 2011 13:09:49 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Hadriel Kaplan <>
X-Mailer: Apple Mail (2.1084)
Cc: "<>" <>
Subject: Re: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Sep 2011 12:07:24 -0000

Yes, essentially (plus RTP over UDP for the media, of course).


On 21 Sep 2011, at 12:45, 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.
> 2) Defining DDCP over UDP for message-oriented unreliable data delivery.
> 3) Requiring the browser to implement and only expose those two options for the "data" stream type and not raw UDP, so that we can enforce congestion control of the data channel. (oh, and the option for it to be PseudoTCP/DTLS/UDP or DCCP/DTLS/UDP)
> Correct?
> -hadriel
> On Sep 21, 2011, at 6:47 AM, Colin Perkins wrote:
>> On 21 Sep 2011, at 10:19, Harald Alvestrand wrote:
>>> On 09/20/2011 04:36 PM, Magnus Westerlund wrote:
>>>> On 2011-09-19 21:14, Harald Alvestrand wrote:
>>>>> On 09/19/2011 06:00 PM, Magnus Westerlund wrote:
>>>>>> We need to standardize a number of Transport protocol functionalities for the RTCWEB data transport solution. To the degree that I do like to resurface some of my earlier suggestions around this. Why not use DCCP with TFRC or TCP like congestion control tunneled over UDP.
>>>>>> The whole specification is ready. Which avoids any hiccup with the transport people and IESG.
>>>>> The last few times this has surfaced, the conversation has turned suddenly silent when I've asked where to find a DCCP-over-TFRC stack I can experiment with.... are there any out there that are "production ready"?
>>>> To my knowledge there is a DCCP stack in Linux. Exactly it status is unknown to me and which of the CC it supports. There has been also additional projects for implementations.
>>> I checked out the Linux stack, and concluded that it was:
>>> a) not supporting DCCP over UDP
>>> b) not possible to extract it and embed it in a browser
>>> The only project I could find for userspace DCCP was untouched for at least 3 years, and did not compile.
>> Agreed. The Linux DCCP code seems reasonably mature, but doesn't support the UDP encapsulation. The user-space DCCP-TP code is not in a good state to build upon.
>>>> I would note that no implementation exist of DTLS with a CC algorithm and additional mechanism. Thus that would be a from scratch implementation effort without any input what has been done so far.
>>>> And if we can in fact decide early on something fully specified you have a lot of time to implement this before the rest are standards ready.
>>> My worry is that without the ability to experiment, I have no way of verifying that the protocol satisfies the properties we are attributing to it.
>> This is a little pessimistic. The Linux DCCP code can certainly be used for lab-based experiments, and these can be made to give a reasonable idea of the performance of DCCP with the existing CCIDs. Not perfect, sure, but should be good enough to show whether the basic idea is worth exploring further. 
>> The main reason to consider DCCP-over-UDP isn't running code though, it's the solid specification. I'd argue that it will be easier to start with the DCCP spec, profile it down to what's needed by this group, plug in a new congestion control algorithm (CCID), and implement the result, than it would be to start both the specification and implementation efforts from scratch. As a congestion-controlled, connection-oriented, unreliable datagram service, there's not a lot in DCCP that we wouldn't want for RTCWeb (and those bits we might want to modify, such as the congestion control algorithm, are things where DCCP supports extensions).
>>> Also, we *know* we'll be shipping products well ahead of the standards' final approval, with appropriate warnings that things *will* change between product versions. We don't have "a lot of time".
>>>>> The pseudoTCP stacks in libjingle have seen service for a long time....
>>>> Well, that is addressing another set of requirements namely the reliable data transport. Lets not confuse the two sets. We appear to have interest in both unreliable and reliable data transport.
>>> Yup, I pulled that in as an example of "code maturity".
>>>> Regarding pseudoTCP we still need a specification for it. I think for example the psuedo header used in the checksum needs specification in TCP over UDP. It might not be a big spec, but someone needs to write it and find a home for it. I would note that we are somewhat limited in this WG to actually do protocol work.
>>> It will have to seek approval elsewhere, if needed.
>>>> cheers
>>>> Magnus Westerlund
>>>> --------------------------------------------------------------------
>>>> Multimedia Technologies, Ericsson Research EAB/TVM
>>>> --------------------------------------------------------------------
>>>> Ericsson AB                | Phone  +46 10 7148287
>>>> Färögatan 6                | Mobile +46 73 0949079
>>>> SE-164 80 Stockholm, Sweden| mailto:
>>>> --------------------------------------------------------------------
>>> _______________________________________________
>>> rtcweb mailing list
>> -- 
>> Colin Perkins