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

Magnus Westerlund <> Tue, 20 September 2011 14:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4CB3D21F8C6A for <>; Tue, 20 Sep 2011 07:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.517
X-Spam-Status: No, score=-106.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1mnznjJJ6WQV for <>; Tue, 20 Sep 2011 07:34:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8292021F8548 for <>; Tue, 20 Sep 2011 07:34:19 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-65-4e78a4fc08b2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6D.C2.20773.CF4A87E4; Tue, 20 Sep 2011 16:36:44 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Tue, 20 Sep 2011 16:36:44 +0200
Message-ID: <>
Date: Tue, 20 Sep 2011 16:36:43 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Harald Alvestrand <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
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: Tue, 20 Sep 2011 14:34:20 -0000

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

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

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.


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: