Re: Proposed data channel API

On 11/2/2011 12:53 PM, Justin Uberti wrote:
> On Wed, Nov 2, 2011 at 12:02 PM, Randell Jesup <randell-ietf@jesup.org 
> <mailto:randell-ietf@jesup.org>> wrote:
>
>     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.

Most data users wouldn't be affected if the congestion control was 
separate; applications with large low-priority transfers would likely 
have to implement some form of workaround by optionally throttling their 
writes to the data channel if bandwidth is "low".  Doable, definitely, 
though non-optimal, and it puts a potentially confusing-to-the 
app-writer requirement on them.

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

Ok, so it sounds like 2RTT is not normative; the wording would 
definitely need to be changed.

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

There are two aspects to partial reliability here: out-of-order delivery 
(which is technically separate from reliability per se, but potentially 
useful to applications such as games), and bounds on the time before 
notifying of a reception failure.  I'll note that we're assuming 
unreliable channels are in some manner ACKed; i.e. a stronger contract 
than UDP gives (and of course UDP isn't congestion controlled) - and 
this fits well with SCTP, I believe.

The API given doesn't provide the receiver with any sequencing 
information, though for the packets to be ACKed and losses reported to 
the sender after 2RTT (or whatever), the stack must have that 
informations.  We have the option of providing sequence information to 
the receiver, which is probably very important for out-of-order 
delivery, and probably useful even for in-order unreliable delivery.


-- 
Randell Jesup
randell-ietf@jesup.org