Re: Proposed data channel API

On Wed, Nov 2, 2011 at 12:02 PM, Randell Jesup <randell-ietf@jesup.org>wrote:

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

Yes, this needs to be specified. At a minimum, we could just treat data
channels as flows separate from the media congestion control, as if they
were unrelated browser traffic like XmlHttpRequest. This obviously has
downsides; since the media congestion control being proposed is
delay-sensitive, a large data flow would adversely affect media flows when
bandwidth is limited.


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

I didn't spell this out, but the 2 RTT is just a initial example of the
algorithm to be used here. I think the stack will know the RTT well, from
both media feedback as well as ACKs for the data protocol; note that there
will always be cases where we give up on a unacked packet that eventually
does arrive, so having some false negatives on a route change is not a
major problem IMO.

I'd be interested in hearing your thoughts on partial reliability, as this
might drive the discussion around the right use cases for delivery
notification.

>
>
>
>>  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 Jesuprandell-ietf@jesup.org
>
>