Re: Alternative data API

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.

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

Received on Thursday, 26 January 2012 22:26:03 UTC