- From: Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com>
- Date: Wed, 5 Feb 2014 18:56:43 +0000
- To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>, Martin Thomson <martin.thomson@gmail.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>
- CC: Web-rtc <public-webrtc@w3.org>
> 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). 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. Regards Raju
Received on Wednesday, 5 February 2014 22:32:23 UTC