Re: RTCDataChannel characteristics and failures -API description

On Jan 9, 2014, at 7:06 AM, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> wrote:

> I sent the mail below some time ago. Some good related discussions appeared, but no response on my main proposal to add some detail in the API description about characteristics and failures of RTCDataChannels.
> ---------------------------------------------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/webrtc.html#rtcdatachannel
> there is this paragraph:
> 
> "A 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) or set a time during which retransmissions are allowed (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."
I just realise that maxRetransmitTime, since this time does not limit the time spent
on retransmissions, but it limits the lifetime of the message. So a name lime
maxLifeTime or so makes more sense.

You also asked for allowing to limit the lifetime and the number of retransmissions.
If that should supported, we need to add a corresponding policy to
http://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-00.txt
It would be great to get some feedback soon...
> 
> 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)
Other stuff might already being transferred. So there is not necessary this strict
sequencing.
> 
> 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."
Channels are not monitored. The STUN connection is and the SCTP association is.
> 
> 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.
Best regards
Michael
> 
> 
> Some of the characteristics need to be agreed with the draft-ietf-rtcweb-data-channel and the underlying SCTP.
> 
> 
> Regards
> 
> Gunnar Hellström

Received on Thursday, 9 January 2014 10:39:56 UTC