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

I saw that the 20140127 version of the API description was published.
The comments I had for the RTCDataChannel are still valid, so I repeat 
them here slightly amended.

---------------------------------------------Repeated 
proposal--------------------------------------------------------------------------------------------- 

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/archives/20140127/webrtc.html#rtcdatachannel 
<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 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 can be made up to 5 times if 
needed and not limited by other failure detection mechanisms, 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, or another failure detection method deems the channel 
or PeerConnection failing, the channel 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. No error indication is 
provided to the peers for this situation. If another failure detection 
mechanism deem the channel or PeerConnection failing, the channel is 
closed. Both peers are informed about the state change, but the state 
change can occur at different moments in time for the peers. "


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

"The status of the PeerDataConnection is also monitored through 
heartbeats, and lack of a number of heartbeats from the peer, or closing 
of other channels in the PeerDataConnection or other failure indications 
will cause the connection to be teared down. The status of the 
transmission at the time of failure can be interrogated in the transmit 
buffer as described by the BufferedAmount attribute."

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,
mainly in the parameters of the
onerror
and
onclose
events
in 5.3

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



Regards

Gunnar Hellström