W3C home > Mailing lists > Public > public-webrtc@w3.org > January 2012

Re: Alternative data API

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Mon, 30 Jan 2012 08:28:03 +0100
Message-ID: <4F264683.7070408@ericsson.com>
To: Justin Uberti <juberti@google.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 01/30/2012 02:32 AM, Justin Uberti wrote:
> On Fri, Jan 27, 2012 at 3:58 AM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>     On 01/27/2012 05:21 AM, Justin Uberti wrote:
>         On Thu, Jan 26, 2012 at 5:25 PM, Randell Jesup
>         <randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
>         <mailto:randell-ietf@jesup.org
>         <mailto:randell-ietf@jesup.org>__>> wrote:
>             On 1/26/2012 6:41 AM, Stefan Hakansson LK wrote:
>                 On 01/26/2012 02:59 PM, Harald Alvestrand wrote:
>                     I believe this fails on one of the listed
>         requirements in
>                     draft-jesup (I
>                     note that you listed the use cases, but did not
>         include the
>                     requirements
>                     that Randell inferred from these use cases):
>                 Yes, I did list the use-cases but not the requirements,
>         mainly
>                 because I
>                 could not really go from the use cases and derive (many
>         of) the
>                 requirements. The ones below, possibly with the exception of
>                 Req. 2, are
>                 among those that I could not really derive from the use
>         cases.
>                     Req. 1 Multiple simultaneous datagram streams must
>         be supported.
>             I should note that for games, having multiple streams with
>         different
>             characteristics is a huge plus.  Going *all* the way back to
>         netrek
>             (you can look it up on wikipedia), networked games have used
>             multiple streams.  Netrek used a reliable stream for
>         critical state
>             info ("you're dead"), and unreliable datagrams for general
>             world-state updates ("opponent 3's position is x,y").  One
>         of the
>             reasons for providing the multiple channels is that if we don't,
>             application makers who need them will create their own
>         protocol on
>             top of whatever we provide.  If we provide reliable only,
>         that fails
>             a lot of real-time needs, and if we provide unreliable only
>         they'll
>             build reliable on top of it - badly, and incompatibly.
>         Multi-user scenarios will almost certainly need multiple
>         simultaneous
>         streams, i.e. at least one for each participant. Of course, you
>         could
>         get away with having a single stream and just muxing everything over
>         that stream using an application-defined protocol, but it's probably
>         best for interoperability if we officially support this scenario.
>     I assume that you're talking about multi-user with a central server,
>     otherwise there would be a separate PeerConnection to each user.
>     With the "Alternative Data API" muxing of DOMString data is
>     straightforward (to do in the application); blobs and ArrayBuffers
>     is another story. There ChannelMessaging should be possible to use
>     to create channels, but I've not looked into the details (and am
>     unsure about the maturity of ChannelMessaging).
> It's multi-user that is not full mesh, but it might not involve a
> central server (e.g. a directed p2p graph).
> If all the elements in the graph are aware of the application protocol,
> this would certainly work, even with ArrayBuffers. The app could create
> its own packet format, and use that to create its own multiplexing
> mechanism, and even its own reliability and priority mechanism (it would
> of course have to depend on the PeerConnection's congestion control
> mechanism).
> This might allow us to make the in-browser code substantially simpler,
> as it would just be a secure pipe for generic datagrams at this point.
> All the advanced stuff would be done through JS libraries.
> I think this is a important point for the WG to consider. Would folks
> rather have a simpler, less capable API that we can ship sooner?
> I admit that doing SCTP or PseudoTCP in Javascript sounds interesting.

I must admit I never thought that far. My idea was more to have a simple 
API (much aligned to WebSockets) for a start, and then add functionality 
if needed (with e.g. the options argument); but having SCTP as the 
underlying transport.

I think that also with the simple start API you can get a lot of 
functionality by combining it with other tools in the web platform (and 
the app can perhaps prioritize between its own data).

But I think your question (i.e. doing protocol in JS) is valid indeed.

>                     There is also no support for:
>                     Req. 2 Both reliable and unreliable datagram streams
>         must be
>                     supported.
>                     Req. 4 The application should be able to provide
>         guidance as
>                     to the
>                     relative priority of each datagram stream relative
>         to each
>                     other,
>                     and relative to the media streams.
>             This ties back to the congestion control issues.  The data
>         channel
>             must be congestion controlled, and depending on the use case
>         one or
>             the other may want priority for bits on the wire.
>                     While these COULD be done with the suggestion of "add
>                     options" under
>         "future extensions", I think this seems like a clear and present
>                     requirement.
>                     A number of the other requirements aren't really
>         relevant to
>                     the API,
>                     being more protocol related, but these 3 seem to be
>                     impossible to
>                     satisfy without corresponding API functionality.
>                 I agree. I think 2 and 4 are very straightforward to
>         fulfill, and 1
>                 needing some more work - but then again there has been
>         little
>                 evidence
>                 of the need, and my input was more on offering a "do
>         less now, add
>                 things if there is need" approach.
>             Well, from the JS API end that might be the case, but from
>         the IETF
>             bits-on-the-wire side, we need to define the protocol, and
>         it's hard
>             to upgrade those later without major backwards-compatibility
>         pain.
>               So, even if we used a single-channel api to start, we'd want a
>             multi-channel-compatible wire protocol underneath it - and
>         it would
>             be hard to test that.
>                     I believe embedding a single-channel data function into
>                     PeerConnection
>                     (and therefore encouraging the deployment of
>                     single-channel-assuming
>                     applications) would make it harder to satisfy this
>                     requirement set later.
>                 Why? I can't see that that the fact that there are
>                 single-channel-assuming applications deployed would stop
>         adding e.g.
>                 multiple-channel support later (as long as the
>         single-channel API
>                 continues to work) if there are use cases demanding that.
>             If you add multi-channel later while keeping single-channel, the
>             final interface might be kindof odd/confusing for someone
>         coming to
>             it cold.
>                 Again, I'm fine with doing the more advanced approach,
>         my input was
>                 mostly to show that there is an alternative approach
>         available
>                 that is
>                 simpler (it may for example allow us to define fewer new
>         events -
>                 something that is not introduced everyday), is better
>         aligned to
>                 existing messaging APIs _but_ less capable.
>                 It is up to the group, and as contributor I will do my
>         best to
>                 make the
>                 selected approach as good as possible (there may on the
>         other
>                 hand be
>                 very little value in that...)!
>             --
>             Randell Jesup
>         randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>
>         <mailto:randell-ietf@jesup.org <mailto:randell-ietf@jesup.org>__>
Received on Monday, 30 January 2012 07:28:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:25 UTC