Re: RTCDataChannel characteristics and failures

On 2014-01-02 19:21, Michael Tuexen wrote:
> On Jan 2, 2014, at 1:36 PM, piranna@gmail.com wrote:
>
>> For example, highly coupled realtime tasks like P2P video distribution. You would be interested in have a timeout to don't send info out of time, but also have a max number of retransmits to don't waste bandwidth and try another source.
> The source would apply the PR-SCTP policy, right? How does the source know that messages
> are abandoned? The socket API for SCTP can provide this information, but how do you know
> this in the JS API. Any idea? Who would change another source, since it can't be the source.
>
> Currently SCTP uses an enumeration of policies. To do the above, we would need to
> extend it to handle logical ands and ors of policies. That would required some
> changes to
> https://tools.ietf.org/search/draft-ietf-tsvwg-sctp-prpolicies-00
>
> What do others think?
I think the application can do the combination, by asking the channel to 
use the retry limit and the application having a timeout when it looks 
at the transmit queue, and if it has not moved the application can give up.

There is sufficient complication in the protocols and APIs to handle the 
current policies, and we are lacking information in the API description 
for what happens in different failure and abandoning situations.

When I have analyzed the data channel, I have come to the conclusion 
that the application needs to handle its own sequence number and 
sequence number checking. It first sounds as overkill, but I think it is 
not. The reliable and semi-reliable channel types may break by reaching 
the retransmission limit of SCTP, and the logical action of the 
application is to reconnect and continue. If detection of loss is of 
importance, then a sequence number that spans over a break and reconnect 
seems needed.
Or, is there any built-in support for that?

Gunnar


Best regards Michael
>> Send from my Samsung Galaxy Note II
>>
>> El 02/01/2014 09:36, "Harald Alvestrand" <harald@alvestrand.no> escribió:
>> On 12/30/2013 12:09 AM, piranna@gmail.com wrote:
>>
>>>> for some use cases...
>>> Any concrete example?
>>>
>> Application-based fine-grain control of the transmissions.
>>
>> When asked for a concrete example, please give a concrete example of an application that needs it.
>>
>> It's always possible to send in unreliable mode and implement your own mechanisms for reliability; any extension to the spec needs to be backed with an use case that makes it clear why it's worth changing.
>>
>>
>

Received on Thursday, 2 January 2014 20:31:42 UTC