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

On 2/10/2012 6:57 PM, Cullen Jennings wrote:
> On Feb 7, 2012, at 10:10 AM, Stefan Hakansson LK wrote:
>
>> Agreed
>> ======
>> * The API should allow for the application to use multiple channels
>> (without having to to do muxing in the app)
> I don't care if we have this or not. On the pro side, it is something SCTP provides. On the con side, none of our causes cases need it as far as I can tell. And you can always set up more than one DataStream. It does make it harder to replace SCTP with a TCP like thing if we find problems with SCTP. I do worry that channels will make this hard to use an API that matches up with websockets.


You can always fairly trivially replace the underlying SCTP with a 
mux/demux over a single connection (whether that be raw DTLS, WebSocket, 
carrier pigeon, etc) or multiple connections.  The point is we're 
providing the multiple channel abstraction to the app, and the channels 
can have varying characteristics.  (If I had to replace SCTP, I'd do it 
with a simple protocol on top of DTLS, since you can't really emulate 
unreliable over a reliable connection.)

Perhaps this is a disconnect point - I should note that several of the 
use-cases (games, file transfers) and uses discussed on the list imply a 
need to do multiple simultaneous transfers of data, including cases 
where you need both reliable and unreliable data.  Either we provide 
multiple channels, or the application must mux the data by hand (and 
then if they need both reliable and unreliable they'd need to use 
unreliable and implement reliable on top of that in JS).

If an app wants to mux all their data onto a single dataChannel (perhaps 
because they're porting something that works over a single socket 
today), that's fine, and up to them.

>> * The API should allow the application to select reliable or unreliable
>> transmission (where "reliable" also means "in order delivery")
> Yes - and to be clear, I care more about "unreliable" deliver than reliably. As soon as you select "reliable" in SCTP, it means you basically don't care about real time and thus you probably could have sent that data over websockets via the server. The thing I can't do that way is real time data and thus the thing I really need here is "unreliable". That said, I do think we should have "reliable" as well.


Right, for all the reasons agreed to long ago in the IETF list.   
Another thing impossible to emulate on a TCP connection is 
partial-reliability, and a pain to do by hand in your app on a 
fully-unreliable one, so we may want to expose that as well.

>> * The API should allow the application to check if data is being
>> buffered (so that it can adjust the send rate)
> uh - I have no idea what this even means. Of course it is buffered - it's a transport. Need to know more.


This is basically saying "if the data is being buffered due to 
congestion control, the app should be able to find that out so it can 
change its behavior".  In some cases the app is not interested in 
sending data if too much data is buffered already, as it won't get onto 
the wire quickly enough, or the app may want to change what data is sent 
(eliminating optional nice-to-have data), or change encodings.

>> * 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)
> In general agree, but having a hard time seeing what this means


It doesn't really mean much other than "we might want to add more 
options later", and that the wire protocol should support that (no problem).

>> Open
>> ====
>> * Should the API be uni- or bi-directional?
> I will argue very strongly for bi-directional. It makes is much easier to to protocol where you send a request and expect a response to that request. It's what programmer expect. There pretty much no reason not to.


Ok.  There are quite a few potential unidirectional uses, especially 
when you get into multiple streams of data, but this really doesn't cost 
much to provide (especially if we need to signal 'open' back to the 
other side), and it simplifies the model/API for the user some.

>> * 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")?
> It should not buffer data before open because then it is hard to deal with what error to return if there is an error forming the data. (perhaps it returns an error if you try and send before it is open). The application should find out it is "open" in a way that mirrors how it works for audio and video streams.


Ok.


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Saturday, 11 February 2012 03:33:19 UTC