WebRTC channel reliability
All of your assumptions are correct.
For the first and second case, not setting maxRetransmits and maxPacketLifeTime results in a reliable channel according to the section 6.2 RTCDataChannel of WebRTC W3C Recommendation, which is the following (bold and italics mine):
An
RTCDataChannelcan be configured to operate in different reliability modes. A reliable channel ensures that the data is delivered at the other peer through retransmissions. An unreliable channel is configured to either limit the number of retransmissions (maxRetransmits) or set a time during which transmissions (including retransmissions) are allowed (maxPacketLifeTime). These properties can not be used simultaneously and an attempt to do so will result in an error. Not setting any of these properties results in a reliable channel.
The third case, which is setting ordered: false and maxRetransmits: 0, creates an unreliable and unordered channel like UDP according to RFC8831 section 6.1, which is the following (bold and italics mine):
- The partial reliability extension defined in [RFC3758] MUST be supported. In addition to the timed reliability PR-SCTP policy defined in [RFC3758], the limited retransmission policy defined in [RFC7496] MUST be supported. Limiting the number of retransmissions to zero, combined with unordered delivery, provides a UDP-like service where each user message is sent exactly once and delivered in the order received.
The fourth case, which is setting ordered: true and maxRetransmits: 0, creates an unreliable but ordered("sequenced") channel. This type of channel exists according to a paragraph of RFC3758 section 1.3, which is the following (bold and italics mine):
- In addition to providing unordered, unreliable data transfer as UDP does, PR-SCTP can provide ordered, unreliable data transfer service.
About the fourth case, I don't know exactly how "ordered" is implemented on an "unreliable" data channel. But I think the guess in here https://jameshfisher.com/2017/01/17/webrtc-datachannel-reliability/ would be right. The receiver may discard earlier messages if they arrive after later ones.
This guess seems right according to the last paragraph of RFC3758 section 3.6, which is the following (bold and italics mine):
Note that after receiving a FORWARD TSN and updating the cumulative acknowledgement point, if a TSN that was skipped does arrive (i.e., due to network reordering), then the receiver will follow the normal rules defined in RFC 2960 [2] for handling duplicate data. This implies that the receiver will drop the chunk and report it as a duplicate in the next outbound SACK chunk.
RFC3758 is refered by RFC8831 section 5, which is, in turn, refered by WebRTC W3C Recommendation.