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

On 2014-01-28 08:33, Gunnar Hellstrom wrote:
> 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,
> <>
> 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."
> 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.

Does the silence mean that people agree and are fine with these changes 
going into the spec? If anyone have any comments or suggestions, please 


Received on Tuesday, 4 February 2014 11:52:40 UTC