Re: [rtcweb] PeerConnection Data Channel

On Fri, Sep 2, 2011 at 6:13 PM, Randell Jesup <randell-ietf@jesup.org>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>
>