Re: Alternative data API

On Fri, Jan 27, 2012 at 3:58 AM, Stefan Hakansson LK <
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**>> 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.

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