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 10:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0136221F8C72 for <>; Wed, 21 Sep 2011 03:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.527
X-Spam-Status: No, score=-103.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Rg5olmNWUj0w for <>; Wed, 21 Sep 2011 03:45:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0991321F8C07 for <>; Wed, 21 Sep 2011 03:45:10 -0700 (PDT)
Received: from ([]) by with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1R6KL3-0002wS-nu; Wed, 21 Sep 2011 10:47:37 +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 11:47:36 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <>
To: Harald Alvestrand <>
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 10:45:11 -0000

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