Re: [rtcweb] Data transfer

Randell Jesup <> Mon, 19 September 2011 04:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7621D21F8AF7 for <>; Sun, 18 Sep 2011 21:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_43=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IjTvIwEvUvUz for <>; Sun, 18 Sep 2011 21:24:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7053321F8AF5 for <>; Sun, 18 Sep 2011 21:24:46 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1R5VRj-0006zT-Nc; Sun, 18 Sep 2011 23:27:07 -0500
Message-ID: <>
Date: Mon, 19 Sep 2011 00:23:46 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
Subject: Re: [rtcweb] Data transfer
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: Mon, 19 Sep 2011 04:24:54 -0000

On 9/16/2011 10:40 AM, Magnus Westerlund wrote:
> On 2011-09-16 16:16, Iñaki Baz Castillo wrote:
>> 2011/9/16 Magnus Westerlund<>om>:
>>> The argument for having a peer to peer unreliable datagram channel has
>>> been two:
>>> 1) Minimal delay by direct peer-to-peer connection instead of going
>>> through a central server. This as you can't normally establish a
>>> websocket connection to a browser behind a NAT/FW.
>>> 2) Scalability by not requiring a server or having to handle the data
>>> flows at all on the server side.
>>> As an individual I think these arguments are good, and assuming we can
>>> find a reasonable solution that fulfills the requirements we should
>>> specify it.
>> I'm not opposed to such mechanism if approved. But given the current
>> WWW reality, web applications always use HTTP for carrying
>> long-data/documents between client and server, or
>> client-server-client.
> As I said in another email in this thread the WG have had discussion of
> also peer to peer reliable data transport that are capable of handling
> larger data object transfers between the peers. However, the discussion
> didn't result in a clear consensus for this case. Nor a proponent
> surfaced that has continued driving the case.

I'm a strong proponent of a reliable channel as are the other Mozilla folk,
and thought that several of our existing use-cases covered this.  For
example a two (or multi) player game - games frequently use both unreliable
channels (to avoid freezing the game if certain non-critical updates are
lost) and reliable data ("you're dead", etc).  This has been the case since
the earliest days of real-time games on the internet (before the web
existed; see the 'netrek' game/protocol for example).

There are many other uses of peer-to-peer data, such as file-transfer during
chat(you want reliable or you get to re-invent a reliable protocol over UDP),
VNC-like screen updates (probably unreliable with a recovery mechanism),
mouse/keyboard events when doing remote assistance (reliable), etc.  There are
some interesting peer-to-peer mesh protocols which would benefit from reliable
data that might be possible to layer on top of webrtc; we'll likely be
investigating this at mozilla.

You also don't want websockets for data channels here; you want it tied to
the webrtc session and you don't want the overhead/cost/delay of having to
do a separate relay.

>> Also I don't think that data transfer can be achieved using an
>> unreliable data channel (so UDP), is it? For example in SIP protocol
>> MSRP has emerged for this purpose (data transfer) and it uses TCP/TLS
>> as transport, so MSRP relay servers are required when both endpoints
>> are behind NAT.
> I think we all agree that for NAT traversal we are expecting it to be
> IP/UDP/FOO. And it is most likely IP/UDP/DTLS/FOO to have confidential,
> source authenticated and integrity protected transfers. Where FOO
> provides congestion control and possible some type of framing or stream
> concept. But the actual solution is still very early in the discussion.

Yes, see the congestion control discussion occurring now.

> When it comes to data transfer, of course you can achieve reliable
> transport over an UDP. I think I can mention several different methods
> in how to achieve it.
> 1. In this context one option is to implement a reliability function in
> JS, that buffer and retransmit lost data.
Yes; the VNC example above might do this.

> 2. Another one would be to use NORM (RFC5740) as the transport protocol
> inside DTLS. NORM provides both congestion control and reliability. Yes,
> it might have a few over designed features being intended for multicast.

Interesting; I'll take a look.  Thanks.

> 3. Use TCP over UDP
This is what I had been assuming we'd do.  It might have been nice to use
SCTP-over-UDP instead; that would cover more cases without having to drop
into doing network protocols in javascript for example, but it doesn't
appear there's an extant open-source example, so it's a hard sell.

Randell Jesup