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

Randell Jesup <randell-ietf@jesup.org> Mon, 19 September 2011 07:23 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 C05B521F8B66 for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.505
X-Spam-Level:
X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599]
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 e8KY6A7F-5gt for <rtcweb@ietfa.amsl.com>; Mon, 19 Sep 2011 00:23:30 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 3549B21F8B5A for <rtcweb@ietf.org>; Mon, 19 Sep 2011 00:23:30 -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 1R5YEi-0007ti-3E for rtcweb@ietf.org; Mon, 19 Sep 2011 02:25:52 -0500
Message-ID: <4E76EDB6.8090004@jesup.org>
Date: Mon, 19 Sep 2011 03:22:30 -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: <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>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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] 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 07:23:30 -0000

On 9/17/2011 1:27 PM, 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(?).

Actually DTLS channels; they're effectively UDP, but encrypted.  However,
per a few messages you'll have seen from me, discussion at the last IETF
and the call a week and a bit ago, we will plan to extend the congestion
control domain to include controlling the data channels.  Ironically
reliable data channels would be easier to handle than unreliable (you
could just use TCP-over-UDP); but we plan to do better than that.


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

Well, depending on how the data channels are set up, they may not be required
to include in the SDP at all; they could be instantiated on-demand in the
of an open PeerConnection.

Data channels at this point are assumed to be application-specific and not
subject to being exchanged during federation; we should think a little about this.


-- 
Randell Jesup
randell-ietf@jesup.org