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

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 19 September 2011 15:58 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EE70821F8C85 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:58:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.512
X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7Cg-Fozd7Cbv for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 08:58:35 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id 2AFC821F8C81 for <rtcweb@ietf.org>; Mon, 19 Sep 2011 08:58:35 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-28-4e776739cdac
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain []) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.57.02839.937677E4; Mon, 19 Sep 2011 18:00:58 +0200 (CEST)
Received: from [] ( by esessmw0247.eemea.ericsson.se ( with Microsoft SMTP Server id; Mon, 19 Sep 2011 18:00:58 +0200
Message-ID: <4E776739.4010609@ericsson.com>
Date: Mon, 19 Sep 2011 18:00:57 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF510F0C0A@sonusinmail02.sonusnet.com> <05CAC192-E462-421F-B1E5-B78DC8F60306@ag-projects.com> <2E239D6FCD033C4BAF15F386A979BF510F0C93@sonusinmail02.sonusnet.com> <4E73C056.2090003@skype.net> <253421CC-AC2C-4896-8F63-68752F15C621@edvina.net> <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com>
In-Reply-To: <40AA097E-47BD-44C7-B3E8-F7C056FCD43D@acmepacket.com>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: [rtcweb] Data Transport, was: Re: RTCWeb default signaling protocol [was RE: About defining a signaling protocol for WebRTC (or not)]
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Sep 2011 15:58:36 -0000

On 2011-09-17 19:27, Hadriel Kaplan wrote:
> On Sep 17, 2011, at 4:27 AM, Olle E. Johansson wrote:
>> They will be able to use the rtcweb data channel, which is a
>> concern.
> Yes, that's actually the most interesting piece of this whole thing,
> in my opinion.  Browsers don't typically offer raw sockets to
> javascript as far as I know.  And not only does it raise a lovely set
> of security concerns, but also network collapse issues since UDP has
> no congestion backoff and I believe the data channel we're talking
> about is UDP(?).

Well, it is something over UDP. We clearly need UDP for NAT traversal
considerations. However, we also clearly need congestion control
implemented in the browser, not in the JS to prevent two targets to
unfairly saturate the path between the peers.

> And since the data channel is actually peer-to-peer rather than
> client-to-server, the issues with not standardizing its protocol
> become harder. I.e., leaving it a raw socket will only work if it
> goes between the same javascripts, inside the same domain - if that's
> ok, then the only issue is this would be put into SDP, and SDP isn't
> constrained by a javascript domain.  Hmm... gosh, if only rtcweb
> didn't use SDP as its browser API... :)

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.

We can run either IP/UDP/DCCP/DTLS or specify the reverse if we want to
protect also DCCP headers by defining IP/UDP/DTLS/DCCP.

The main argument has been against implementation readiness of this
solution. I would note that any homegrown solution will also not be
implemented and available. And there do exist some stack implementations.

And when it comes to complexity, one will realize that most functions
are in fact needed anyway.


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: magnus.westerlund@ericsson.com