Re: [rtcweb] PeerConnection Data Channel

Justin Uberti <juberti@google.com> Sat, 03 September 2011 03:49 UTC

Return-Path: <juberti@google.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 2376D21F8C30 for <rtcweb@ietfa.amsl.com>; Fri, 2 Sep 2011 20:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.699
X-Spam-Level:
X-Spam-Status: No, score=-104.699 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, 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 Z2vrk4BJpUae for <rtcweb@ietfa.amsl.com>; Fri, 2 Sep 2011 20:49:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0CAC21F8C11 for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:49:37 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p833pDBH004480 for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:51:14 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315021874; bh=dh4vEdnbCx5g133otnYsJdY9epc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aEg4sriORrc1IvWqlxrVb9LW6iHDENa8ltUGqVCzWAriF72KZoFtViu1DMbcaPHFp eZi7zLid7SBVGgGVV/t1Q==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=G+BdWzbCBuKiLnXqB0eIJ1ssxV9tEN1dk0uZZnSN/ncbrFWfnQoj5M0AYzk8oVGjm DeELcZcQDWC3h3u7m3FZA==
Received: from iage36 (iage36.prod.google.com [10.12.207.36]) by wpaz9.hot.corp.google.com with ESMTP id p833ohlF009691 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Fri, 2 Sep 2011 20:51:12 -0700
Received: by iage36 with SMTP id e36so5332865iag.23 for <rtcweb@ietf.org>; Fri, 02 Sep 2011 20:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Tk6hupDiGKC2K5FRs9EOtveFD9kiAKK7naBnvXABXOY=; b=CnUGi3REcm3jn2SWFXu/CxXYnRxgUer0HZ0xJQI5LVWsyRqNkXct3o9L5vSHNj5Lgw 5LFxot/8uYkt5wRLyA1Q==
Received: by 10.231.41.69 with SMTP id n5mr3194253ibe.92.1315021871336; Fri, 02 Sep 2011 20:51:11 -0700 (PDT)
Received: by 10.231.41.69 with SMTP id n5mr3194226ibe.92.1315021870148; Fri, 02 Sep 2011 20:51:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.10 with HTTP; Fri, 2 Sep 2011 20:50:49 -0700 (PDT)
In-Reply-To: <4E615505.70508@jesup.org>
References: <CAOJ7v-1xEEA3+AX0hN4kR=9YggX7EW=wr4b67ASjibG_T=m2mQ@mail.gmail.com> <4E610B78.7000103@skype.net> <4E615505.70508@jesup.org>
From: Justin Uberti <juberti@google.com>
Date: Fri, 2 Sep 2011 23:50:49 -0400
Message-ID: <CAOJ7v-1+uM7VGiG11MXXEr9dK+_j_MLXBMS-D23S0ZYZG8zG0A@mail.gmail.com>
To: Randell Jesup <randell-ietf@jesup.org>
Content-Type: multipart/alternative; boundary=0015177407d4712b1504ac01635b
X-System-Of-Record: true
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, public-webrtc@w3.org
Subject: Re: [rtcweb] PeerConnection Data Channel
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: Sat, 03 Sep 2011 03:49:39 -0000

On Fri, Sep 2, 2011 at 6:13 PM, Randell Jesup <randell-ietf@jesup.org>wrote;wrote:

> CC-ing IETF rtcweb to cover the encryption/SDP/negotiation aspects of this
> proposal.
>
>
> On 9/2/2011 12:59 PM, Matthew Kaufman wrote:
>
>> On 9/2/11 5:52 PM, Justin Uberti wrote:
>>
>>> Section 5 in the WEBRTC spec (http://dev.w3.org/2011/**
>>> webrtc/editor/webrtc.html<http://dev.w3.org/2011/webrtc/editor/webrtc.html>)
>>> discusses at length a mechanism for transmitting and securing datagrams over
>>> the PeerConnection transport. At both an API and a wire level, this
>>> mechanism is quite different from the existing mechanisms that are used for
>>> transmission of audio and video data:
>>> - The availability of the data stream is not easily known, whereas
>>> audio/video can be negotiated and stream existence learned from the *Stream
>>> methods/callbacks.
>>>
>>
>> Agree.
>>
>
> True
>
>
>  - It defines its own encryption mechanism, whereas audio/video will use
>>> SDES-SRTP, or DTLS-SRTP
>>>
>>
>> Agree.
>>
>
> True, kinda, but that's not a value judgement, just an observation.
>
>
>
>>  - Only one data stream exists, whereas audio/video can have many streams
>>>
>>
>> Agree.
>>
>
> True
>
>
>
>>
>>> I would like to propose an approach where we remove the send() method,
>>> and add a createDataStream() method to PeerConnection. This method creates a
>>> DataStream object, a descendant of MediaStream. This object can then be
>>> added/removed from PeerConnection via the existing add/removeStream APIs,
>>> and it will show up in localStreams/remoteStreams like any other
>>> MediaStream. It will also fire events indicating the stream status.
>>>
>>
>> Great idea.
>>
>
> I agree ways to create and add datastreams are important, as is the ability
> to have multiple ones.  Otherwise people will just roll-their-own
> multistream muxes.  If there can be only one stream, it would almost have to
> be an unreliable-datagram service, so you could build more complex stuff on
> top of it.
>
>
>
>>
>>> Some specifics:
>>> - This stream will show up in SDP
>>>
>>
>> I don't like SDP, but if we do SDP, that's where it'd need to be.
>>
>>  , and it can be its own RTP session,
>>>
>>
>> Disagree. RTP semantics are inappropriate for sending data. The data
>> should be sent using one of the two methods for muxing data that were
>> proposed (one by me, one by cbran).
>>
>> There should be a way to demux multiple streams of data using an
>> additional sub-header.
>>
>
> Agreed.  RTP for non media-stream data is not a good choice.
>
>
>  or muxed with other RTP sessions, just like any other audio/video stream.
>>> If the remote side doesn't support/want the data stream, it can signal this
>>> via its answer SDP.
>>>
>>
>> Agree.
>>
>
> Agree
>
>
>>  - For encryption, it simply uses the underlying encryption of the
>>> session, i.e. none, SDES-SRTP, or DTLS-SRTP, as appropriate.
>>>
>>
>> Absolutely correct. Possibly needs masking for the "none" case however...
>> need to discuss.
>>
>
> Hmmm....  This (blah-SRTP for encrypting the data streams means full
> un-encrypted RTP headers at a minimum, plus a bunch of those "RTP semantics"
> you disagreed with above.  Unless I mis-understand how this would work.
>
> This (RTP encapsulation of the data) is my biggest heartburn with this
> proposal.  I thought that idea had died at the mic, but apparently not.
>
> The strongest arguments in favor of RTP are: simplify code (everything ends
> up RTP), and RTP provides implicit information about loss and timing
> information that can be of use to congestion-control algorithms.  For
> example, if both audio and video are currently inactive/muted, you still
> want the congestion control/bandwidth estimation code to continue to work
> for data channels.  That in fact might be the strongest argument in favor,
> though there are other ways to provide that information.
>
> So we should detail out the ramifications of this (and think carefully
> about any security implications to SRTP use here, though it's probably ok
> from a security standpoint).


I do think we want common congestion control for audio/video/data. I don't
think this necessarily implies RTP, although it does imply something
RTP-like, so it may just be simplest to go with RTP. As mentioned in my
reply to Bernard, I think this topic merits its own thread.

>
>
>
>>  - Multiple DataStreams can be created, just like MediaStreams. This may
>>> be of value to certain applications, who want to have multiple flows,
>>> perhaps with their own QoS.
>>>
>>
>> Agree. Prioritization makes sense here, especially if/when we get
>> congestion control.
>>
>
> Agree.  I'll use the ancient example of netrek - it wanted and needed both
> a reliable and unreliable channel.  The QOS characteristics of the two would
> have been different as well (if they'd been settable).  Prioritization
> should not just be within data streams, but also it should prioritize
> individual data streams versus media streams.
>
>
>  - We can (perhaps later) add different kinds of DataStreams, i.e. datagram
>>> and reliable. When creating a DataStream, you can specify what kind of
>>> stream you want.
>>>
>>
>> Also a good idea.
>>
>
> Agreed.
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>