Re: RTCDataChannel characteristics and failures -API description - comment to the 20140127 version

On 2014-02-05 19:56, Makaraju, Maridi Raju (Raju) wrote:
>> If an application opens a data channel and requests the unreliable type
>> with maximum 7 retries.
>> And it turns out that the reliable type by default makes maximum 5 retries.
>>
>> Will the channel establishment then accept to extend to 7 retries?
>> Or what will happen?
>>
>> It looks a bit strange to have an unreliable channel that is more
>> reliable than the reliable one.
>> But without documentation about the default retries for the reliable
>> channel this situation might very well happen because the application
>> programmer does not know the figure.
>>
>> If it is agreed that it is illogical to set the unreliable channel more
>> reliable than the reliable one, an addition to the API could say:
>> "If the MaxRetries parameter is higher than the default maximum number
>> of retries used for reliable channels, the channel will use the default
>> number, but in other aspects perform as an unreliable channel (e.g. no
>> channel disconnect after exceeded number of retries)."
> [Raju] I want to point out one of the important characteristic of "reliable channel", which is if data can't be delivered (aftere set retransmissions) then the SCTP association is aborted and closed. This is per SCTP RFC 4960 "8.1.  Endpoint Failure Detection"(http://tools.ietf.org/html/rfc4960#page-100).
Good.
This is my *assumption* of what would be the result of that failure. 
Please verify:

It will cause an onerror callback. And an onclose as well?
At least the onerror would need a reason parameter, indicating 
transmission error.
What was successfully transmitted may approximately be judged by looking 
at the remaining sendbuffer. But there is always a risk that the 
receiver received something successfully but the sender never got the 
acknowledgement, so exact state cannot be judged.
The receiving side will at least get an onclose callback. That will be 
either by signaling from the sender or by timeout on of heartbeats on 
the channel.

There is also an ICE continuity check that can fail in bad 
communications environments and cause the SCTP association to abort and 
close.  This can happen also for an unreliable channel.
That type will be signalled by an onerror callback, and a parameter 
indicating the problem type. Both ends will get the indication and both 
reliable and unreliable channels will be closed.

Note that heartbeats and ICE connectivity checks can cause failure also 
on idle channels.

> But with "unreliable channel", data is attempted per retransmission parameters and the SCTP association stays up even if data can't be delivered after all the attempts are exhausted.
> What this means is, by using unreliable channel a single chat message failure won't drop the entire chat session.
>
> So, IMHO, having unreliable data retransmitted more times than reliable is not bad and may be desired by some applications (e.g. retransmit faster and give up sooner) and it is upto the application to set those parameters diligently. Having said that, keeping a reasonable upper limit on # of retransmissions and retransmission interval makes lot of sense though; but tying them to reliable channel parameters is not needed.
Yes, I realize that that is not as illogical as it first appears by the 
type names.

Thanks
Gunnar
>
> Regards
> Raju