Re: [rtcweb] Data transfer

Randell Jesup <randell-ietf@jesup.org> Mon, 19 September 2011 04:24 UTC

Return-Path: <randell-ietf@jesup.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7621D21F8AF7 for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 21:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.213
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjTvIwEvUvUz for <rtcweb@ietfa.amsl.com>; Sun, 18 Sep 2011 21:24:53 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 7053321F8AF5 for <rtcweb@ietf.org>; Sun, 18 Sep 2011 21:24:46 -0700 (PDT)
Received: from pool-173-49-141-165.phlapa.fios.verizon.net ([173.49.141.165] helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <randell-ietf@jesup.org>) id 1R5VRj-0006zT-Nc; Sun, 18 Sep 2011 23:27:07 -0500
Message-ID: <4E76C3D2.1010005@jesup.org>
Date: Mon, 19 Sep 2011 00:23:46 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <CALiegfnOx9VeW6vmoHHV2Aopo1ECK7Ud51Lo0o0pAVBi=6LRjQ@mail.gmail.com> <4E7358AC.8030509@ericsson.com> <CALiegfk_Wza-y61N6Scx6dSuT77XwjBnWhGe5wPBt2-zTxfhYA@mail.gmail.com> <4E735FC8.20906@ericsson.com>
In-Reply-To: <4E735FC8.20906@ericsson.com>
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 - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: Re: [rtcweb] Data transfer
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 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<magnus.westerlund@ericsson.com>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
randell-ietf@jesup.org