Re: RTCDataChannel characteristics and failures

On 2014-01-02 21:53, Michael Tuexen wrote:
> On Jan 2, 2014, at 9:31 PM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
>
>> 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
> Hmmm. Interesting. SCTP gives up when it thinks the peer can't be reached anymore.
> With tuning the parameters, it will try pretty hard. Why do you think retrying the
> connection makes things easier? Doesn't ICE do also connectivity checks? Why should
> ICE report that the peer is reachable, but SCTP can't?
I read SCTP as if it will do one original and a maximum of 5 
retransmissions. In bad network conditions, it will not at all be 
eternity between failures of all 6 transmissions.
A factor limiting the likelihood of success is that you rely on both the 
forward transmission and the feedback transmission to work in order to 
regard the transmission successful. So, you can get stuck retrying even 
if the receiver got the data.
I know you said that it might not be the path limit of 5 retries that 
should be used but possibly imore towards the 10 Association retries. 
But that also increases the stall time during retransmissions so that at 
least the real-time text data I am thinking of would be severely stale 
when the channel finally succeeded or broke.

Already the 5 retries could span over 30 to 60 seconds on rapid 
networks, so I do not think it is realistic to extend the retry number 
over 5.

It of course all depends on what packet loss rate you need to calculate 
with, if you have a type of communication that need to work also in 
catastrophy situations.

My brief calculations indicate that in a bad situation with 15% packet 
loss, and the reliable channel used for rea-time text time sampled and 
transmitted at 300 ms intervals would experience more than 10 seconds 
stalling once per minute and break of the channel after 30 seconds 
stalling for retries would happen with a mean interval of 11 minutes.

What else can an application do than reconnect and offer the user to 
continue?

At up to about 3 % packet loss it seems to perform excellently and can 
really be called reliable.

A first action would be to include information in the API about how 
various kinds of failures are signaled.

And for the application of real-time text we still need to consider all 
the alternatives discussed about a year ago:
RTP
Reliable data channel
Semi-reliable data channel with a timeout that the user can accept and 
reconnection for continuing.
Unreliable data channel and forward error correction applied.
Transmission external to webrtc, through WebSocket or so and proper 
action against long stalling in failure situations.


A first action would be to include information in the API about how 
various kinds of failures are signaled, as I have made an initial 
proposal earlier in this thread.

Regards,

Gunnar



>
> Best regards
> Michael
>> 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 22:26:05 UTC