Re: [rtcweb] Data transfer

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 16 September 2011 14:37 UTC

Return-Path: <magnus.westerlund@ericsson.com>
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 A2CD921F8C28 for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.354
X-Spam-Level:
X-Spam-Status: No, score=-106.354 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 rW+zgKA8UIhN for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:37:56 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A78B421F8C29 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 07:37:55 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-0d-4e735fc946d5
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B4.1B.20773.9CF537E4; Fri, 16 Sep 2011 16:40:09 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Fri, 16 Sep 2011 16:40:08 +0200
Message-ID: <4E735FC8.20906@ericsson.com>
Date: Fri, 16 Sep 2011 16:40:08 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <CALiegfnOx9VeW6vmoHHV2Aopo1ECK7Ud51Lo0o0pAVBi=6LRjQ@mail.gmail.com> <4E7358AC.8030509@ericsson.com> <CALiegfk_Wza-y61N6Scx6dSuT77XwjBnWhGe5wPBt2-zTxfhYA@mail.gmail.com>
In-Reply-To: <CALiegfk_Wza-y61N6Scx6dSuT77XwjBnWhGe5wPBt2-zTxfhYA@mail.gmail.com>
X-Enigmail-Version: 1.3.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Fri, 16 Sep 2011 14:37:56 -0000

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.

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

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.

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.

3. Use TCP over UDP

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