Re: RTCDataChannel characteristics and failures -API description -

On 2014-09-05 23:47, Martin Thomson wrote:
> On 5 September 2014 11:14, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:
>> So, you expect that in most cases the retries for a reliable channel will
>> spread over 30 seconds, and if still unsuccessful, the Association and all
>> its channels will be aborted.
> No, my point was that the association timers run longer than the
> timers that govern liveness of a single path.  That means that an
> association can survive a path failure if an alternative path is
> found, and it seems like we have ample time to do that.  Some
> implementations already attempt that process, though I can't speak to
> the efficacy.
>
>> Can you explain how you got that 30 seconds figure?
> https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness
>
Thanks.
So, the normal case with default values for an SCTP reliable channel 
seems to be:

1. SCTP retransmissions.
The transmission retries will be done  at 1 , 3, 7, 15, 31, 63, 127, ... 
seconds after initial transmission
2. SCTP heartbeats
The SCTP heartbeats will be done asynchronously with the data 
transmission with 30 second intervals. Let us assume that it will be at 
12, 42, 72, 102 seconds after data transmission.
3. SCTP Max.Retrans
We have max 10 retransmissions for WebRTCP use of SCTP. In this value is 
both failed data transmissions and failed heartbeats included.
Thus this reason to consider data transmission failed would happen after 
127 seconds with 7 data retransmissions and 3 missed heartbeats. ( my 
earlier calculation of 500 seconds did not take the heartbeat into 
consideration)
When this happens, the association breaks and all data channels within 
it are closed.
4. ICE connectivity
In parallell with that, the ICE consent connectivity check is performed 
with a mean interval of 5 seconds, and if all of them fail within 30 
seconds, the connection shall close. So, that is 6 consecutive 
transmissions of the ICE consent that would have failed.

It is quite likely that we in this case have so bad network that the ICE 
liveliness test will fail before the combined retransmission and 
heartbeat failure. You say that ICE connectivity failure does not 
directly cause association abort. It will depend on the implementation 
if the path is refreshed. Would then the remaining RTCDataChannel 
retransmissions and hearbeats be done over that new path?  Will not the 
normal behavior for the RTCDataChannel be to close all channels on that 
connection at the ICE liveliness check failure?


I think that this information is piling up to something that would be of 
value to insert as an informational box in the API specification with a 
title: Example of retransmissions and connectivity checks for 
RTCDataChannel.


/Gunnar

Received on Saturday, 6 September 2014 06:46:10 UTC