Re: PeerConnection Data Channel

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

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

Received on Friday, 2 September 2011 22:16:35 UTC