Re: Alternative data API

On Thu, Jan 26, 2012 at 5:25 PM, Randell Jesup <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.


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