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

Hadriel Kaplan <> Wed, 21 September 2011 11:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0EE5121F88B6 for <>; Wed, 21 Sep 2011 04:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.522
X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NIEglTtJ+j2v for <>; Wed, 21 Sep 2011 04:42:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E1C3521F88A0 for <>; Wed, 21 Sep 2011 04:42:45 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 21 Sep 2011 07:45:13 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Wed, 21 Sep 2011 07:45:13 -0400
From: Hadriel Kaplan <>
To: Colin Perkins <>
Thread-Topic: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
Thread-Index: AQHMeFPsDHEA8PUAeUCkHcUjuUOWdg==
Date: Wed, 21 Sep 2011 11:45:13 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 11:42:47 -0000

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)



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
> _______________________________________________
> rtcweb mailing list