W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2014

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

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 4 Feb 2014 12:52:15 +0100
Message-ID: <52F0D46F.2050906@ericsson.com>
To: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>, Web-rtc <public-webrtc@w3.org>
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,
> 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.
>

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 
comment.

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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:38 UTC