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

Inline:

On Tue, Feb 7, 2012 at 3:03 PM, Randell Jesup <randell-ietf@jesup.org>wrote:

> 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
>>
>
Agree. The last point implies we need some header information to be passed
to allow the remote side to know if it is getting a DOMString or binary
data. During today's hangout, the PPID field was suggested for this purpose.


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

I was thinking we would have an additional parameter to onmessage that
would contain sequence number and other meta-info for the message.

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


+1

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