Re: [rtcweb] Data transfer

Iñaki Baz Castillo <ibc@aliax.net> Fri, 16 September 2011 14:14 UTC

Return-Path: <ibc@aliax.net>
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 CBA9221F8BEB for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:14:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.649
X-Spam-Level:
X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 9hlnXLDo3dyB for <rtcweb@ietfa.amsl.com>; Fri, 16 Sep 2011 07:14:30 -0700 (PDT)
Received: from mail-qw0-f45.google.com (mail-qw0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4591121F8BA6 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 07:14:30 -0700 (PDT)
Received: by qwg2 with SMTP id 2so1421199qwg.4 for <rtcweb@ietf.org>; Fri, 16 Sep 2011 07:16:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.66.144 with SMTP id n16mr1587402qci.178.1316182604681; Fri, 16 Sep 2011 07:16:44 -0700 (PDT)
Received: by 10.229.79.207 with HTTP; Fri, 16 Sep 2011 07:16:44 -0700 (PDT)
In-Reply-To: <4E7358AC.8030509@ericsson.com>
References: <1C8B5EFA-2205-4B67-A800-4961FD6B116C@edvina.net> <CALiegfnOx9VeW6vmoHHV2Aopo1ECK7Ud51Lo0o0pAVBi=6LRjQ@mail.gmail.com> <4E7358AC.8030509@ericsson.com>
Date: Fri, 16 Sep 2011 16:16:44 +0200
Message-ID: <CALiegfk_Wza-y61N6Scx6dSuT77XwjBnWhGe5wPBt2-zTxfhYA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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:14:30 -0000

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.

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.

Regards.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>