Re: Proposed data channel API

Thanks to everyone involved (Justin, etc) for taking the rtcweb data 
proposal and creating equivalent  W3C proposals.

Comments inline...

On 11/1/2011 4:49 PM, Justin Uberti wrote:
> The document at the link below has been updated with feedback from 
> yesterday's discussion, specifically:
> - initial section on security added
> - minor changes to make DataStream more like WebSockets 
> (sendMessage->send, added bufferedAmount)
> - Added DataStream ctor
>
> Open issues:
> - Use case for acking of unreliable sends
> - onReadyToSend: WebSockets requires polling to determine when 
> bufferedAmount == 0. The onReadyToSend callback provides a way to 
> handle this more cleanly, and it's optional, so I'm reluctant to 
> remove it.
>
> On Mon, Oct 31, 2011 at 12:50 AM, Justin Uberti <juberti@google.com 
> <mailto:juberti@google.com>> wrote:
>
>     https://docs.google.com/document/pub?id=16csYCaHxIYP83DzCZJL7relQm2QNxT-qkay4-jLxoKA
>
>     *
>     *
>
>     A proposal
>     for<http://dev.w3.org/2011/webrtc/editor/webrtc.html>http://dev.w3.org/2011/webrtc/editor/webrtc.html,
>     to discuss in tomorrow's TPAC meeting.
>
>
>           5 The data stream
>
>     In addition to the MediaStreams defined earlier in this document,
>     here we introduce the concept of DataStreams for PeerConnection.
>     DataStreams are bidirectional p2p channels for real-time exchange
>     of arbitrary application data in the form of datagrams.
>     DataStreams can either be reliable, like TCP, or unreliable, like
>     UDP, and have built-in congestion control, using a TCP-fair
>     congestion control algorithm.
>
>     DataStreams are created via the new
>     PeerConnection.createDataStream method. This method creates a new
>     DataStream object, with specified "label" and "reliable"
>     attributes; these attributes can not be changed after creation.
>     DataStreams can then be added to a PeerConnection, much in the
>     same way that MediaStreams are added. Since the semantics of the
>     existing addStream API don't fit perfectly here (i.e.
>     MediaStreamHints), we add the new addDataStream and
>     removeDataStream APIs for this purpose. As with
>     addStream/removeStream, these APIs update the internal session
>     description of the PeerConnection, and cause a new offer to be
>     generated and signaled through the PeerConnection signaling
>     callback. Note that there is no requirement to add a MediaStream
>     first before adding a DataStream; rather, it is expected that many
>     uses of PeerConnection will be solely for application data exchange.
>
>     Like MediaStreams, multiple DataStreams can be multiplexed over a
>     single PeerConnection. Each DataStream has a priority, which
>     indicates what preference should be given to each DataStream when
>     a flow-control state is entered. DataStreams with the highest
>     priority are given the first notification and ability to send when
>     flow control lifts.
>

Should anything be said about relative priorities of data streams versus 
media streams?  And perhaps unlike data streams versus data streams, 
relative priorities versus media streams may not be absolute, since 
media streams can suck up any bandwidth available.  Should the 
application be able to reserve a % or  a minimum bitrate for data and 
minimum for media?  And what happens when the available bitrate drops 
below that amount?

>     In reliable mode, in-order delivery of messaging is guaranteed,
>     which implies head-of-line blocking. In unreliable mode, messages
>     may arrive out of order. In either mode, notifications of message
>     delivery are communicated to the application via a callback; in
>     unreliable mode, failures (defined as an elapsing of 2 RTT without
>     an acknowledgement) are communicated through the same callback.
>

Is 2RTT a hard requirement?  It will constrict the options available for 
implementation I imagine, and provides a semi-stated requirement to 
inform the application "soon" after 2RTT (though it's unclear if the 
application will know the RTT, even if known to rtcweb, and what happens 
if there's a large change in RTT due to a route change in mid-call?)

I realize this is dependent on the selection of the reliability protocol 
in rtcweb (such as SCTP), but if SCTP is selected, that would give the 
option of providing partial-reliability, and might help resolve some of 
these issues.

>
>             5.4 Implementation notes
>
>     It is intended that this API map to the wire protocol and layering
>     being defined in the IETF RTCWEB WG for the data channel. One
>     current proposal for said protocol is
>
>     http://www.ietf.org/id/draft-jesup-rtcweb-data-00.txt, which is
>     believed to match the requirements of this API.
>
>


-- 
Randell Jesup
randell-ietf@jesup.org