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

Harald Alvestrand <> Wed, 21 September 2011 09:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1AF021F8B9D for <>; Wed, 21 Sep 2011 02:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -108.98
X-Spam-Status: No, score=-108.98 tagged_above=-999 required=5 tests=[AWL=1.619, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ufrJE8Kv3L+R for <>; Wed, 21 Sep 2011 02:17:23 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E7D0521F8B92 for <>; Wed, 21 Sep 2011 02:17:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id B738839E0A7; Wed, 21 Sep 2011 11:19:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c5lvkAlHGSYE; Wed, 21 Sep 2011 11:19:48 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id 25A0D39E088; Wed, 21 Sep 2011 11:19:48 +0200 (CEST)
Message-ID: <>
Date: Wed, 21 Sep 2011 11:19:47 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: Magnus Westerlund <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 09:17:23 -0000

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

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