Re: Data API: what is agreed, what is open

On 2/7/2012 12:10 PM, Stefan Hakansson LK wrote:
> Hi all,
>
> trying to summarize the discussion on the Data API, I come to this:

Unless otherwise specified, I agree with the comments here.

> Agreed
> ======
> * The API should allow for the application to use multiple channels
> (without having to to do muxing in the app)
> * The API should allow the application to select reliable or unreliable
> transmission (where "reliable" also means "in order delivery")
> * The API should initially enable sending and receiving DOMString, Blob
> and ArrayBuffer data

We also need to decide how the JS API can be designed to feed back 
out-of-order and loss data for unreliable data (i.e. on an unreliable 
stream, you need to be able to examine the sequence numbers).  It 
probably should be available on all message receptions (though pretty 
much irrelevant for reliable in-order dataChannels).


Are we agreeing that the API is purely a JS-level datagram API, or do we 
split "too-large" blobs/etc into smaller datagrams internally (closer to 
WebSockets)?  Note that for unreliable data, that would require us to 
buffer until all parts of a blob/etc had been received (or throw it all 
away if parts are missing for "too long").  This could be moderately 
complex and require significant memory space for very large blobs, as 
well as requiring our own user-level fragmentation/reassembly code. 
Even for reliable in-order data, if we fragment we must do reassembly 
before delivering it.

If instead we consider the API to be a user-level (typed) datagram API, 
then we (WebRTC) do no direct fragmentation or reassembly, and simply 
rely on the SCTP stack to do that.  There is a (minor?) downside in that 
massive datagrams may block other channels until they're sent; I think 
Randall Stewart was saying they want to fix this.  (Randall?)

I am very much in favor of sticking to a datagram API and not adding 
another layer of fragmentation/reassembly.  If need be, we can suggest 
(as mentioned in the Interim) that applications avoid sending too-large 
blobs.  I think it would be easy to provide some example JS helper 
functions to transfer files while avoiding sending a single humungous 
datagram.

> * The API should allow the application to check if data is being
> buffered (so that it can adjust the send rate)
> * The API should be designed to allow extension in functionality (e.g.
> set priority, set that in-order delivery is not to be used for reliable,
> etc.) and data types (e.g. to introduce Stream once the WebApps WG
> defines it)
>
> Open
> ====
> * Should the API be uni- or bi-directional?

I plan to write it up as unidirectional barring objection.

> * Should there be a specific "open" signal to the application (or should
> the object dealt with when sending only be made available when
> transmission is possible), or should data be buffered until it can be
> transmitted (i.e. the app can always "send")?

Open question.  There are two variants of open: one is wait until the 
other side has reacted to the onadd notification (which would likely 
require us to reserve a stream for control info, which I'm ok with), the 
other is to wait until the channel is available to send into 
(association created and SCTP stream available), but not wait for a 
handshake.  There's an open question here about how incoming data is 
handled and queued for delivery relative to onadd.

Also: we have a receive object; once we set the onmessage attribute, I 
assume any queued data would be delivered (how much can queue?  Probably 
limited by buffer space.)  If the app *doesn't* set onmessage, what 
happens?  If this is a problem, we may need a handshake back to the 
sender (for onopen) when the receiver has set onmessage, and set the 
receive object to drop datagrams if/whenever onmessage isn't set.


> We would like comments, both if you agree to what we state as "agreed",
> and input on what you prefer on the open issues. And of course other
> things we have a agreement on, and other things that are open.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 7 February 2012 20:08:46 UTC