RTCDataChannel characteristics and failures

I would like to see a more detailed description of the characteristics 
and failure handling of the RTCDataChannel.

e.g. in section 5.2,
http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel
there is this paragraph:

"A||RTCDataChannel| 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|can 
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 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannelInit-maxRetransmits>|) 
or set a time during which retransmissions are allowed 
(|maxRetransmitTime 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannelInit-maxRetransmitTime>|). 
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."

1. The second sentence needs modification. No data transmission can be 
totally "ensured".
I suggest to change to:

"In a reliable channel efforts are made to deliver data at the other 
peer through extensive retransmissions and feedback."

2. In order to support the  judgement when a developer want to use the 
unreliable variants, there need to be a description about approximately 
how extensive the retransmissions are for the reliable channel. This is 
hard to describe exactly, because it depends on many factors, such as 
roundtrip delays, activities in other RTCDataChannels etc, but here is a 
proposal to continue with a new sentence after the one dealt with in 1):

"In reliable channels, retransmissions are made up to between 5 and 10 
times if needed, spread over a time that can extend to at least 30 
seconds and sometimes many minutes depending on the roundtrip delays of 
the channel and other factors. If the transmission failures are 
persistent after the maximum retransmissions, the channel's underlying 
transport is closed. Both peers are informed about the state change, but 
the state change can occur at different moments in time for the peers."

3. The information about the unreliable types should have some brief 
information about what happens when they fail to transmit. Proposal to 
add last in this paragraph:

"If the limit is reached and the transmission is still not acknowledged, 
the transmission of the current data is abandoned, and transmission is 
initiated of next queued data item if available."

(if that is what happens)

4. More general information about failures should be provided. Proposal 
to add one more sentence in the same paragraph:

"The status of the channel is also monitored through heartbeats, and 
lack of a number of heartbeats from the peer, or closing of other 
channels in the PeerDataConnection will cause the channel to be teared 
down."

5. Details in the API description.
The indications about the functionality described above and suggested to 
the paragraph in 5.2, then needs to be detailed in the API descriptions 
elsewhere in chapter 5.


Some of the characteristics need to be agreed with the 
draft-ietf-rtcweb-data-channel and the underlying SCTP.


Regards

Gunnar Hellström