Re: RTCDataChannel characteristics and failures -API description -

Regarding the comments on your second suggestion beginning with  *"2. The
reliable mode cannot ensure that data is delivered, it can just make
efforts. It can fail . . . . ."* :

Sorry for confusing you. The reference should have been to the Data Channel
*Establishment* Protocol Section 5.1.

The Table that gives the possible Reliability Parameter values says that
the Parameter is IGNORED for the two 'reliable' modes when establishing a
data channel. From this I assumed/implied that there was NO Limit to the
number of retransmissions or maximum time.

Cheers,
/Barry Dingle


On Mon, Aug 18, 2014 at 3:20 PM, Gunnar Hellstrom <
gunnar.hellstrom@omnitor.se> wrote:

>  Barry,
> Thanks, answers inline:
> /Gunnar Hellström
>  ------------------------------
> On 2014-08-18 01:48, Barry Dingle wrote:
>
>  Gunnar,
>
>  Your changes improve WebRTC 1.0.
>
>  Some comments on them below.
>
>  Cheers,
> /Barry Dingle
>
>
>
> On Sun, Aug 17, 2014 at 4:10 AM, Gunnar Hellstrom <
> gunnar.hellstrom@omnitor.se> wrote:
>
>>  We had some mail list discussions on failure handling in the
>> RTCDataChannel, but nothing has been decided and entered into the spec.
>> http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcdatachannel
>>
>> I suggest the following:
>>
>> 1. Section 5.2, third paragraph, ending with "(TODO: reference needed)"
>>  Replace "(TODO: reference needed)" with the same references as at the
>> end of the first paragraph:
>> " [RTCWEB-DATA
>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#bib-RTCWEB-DATA>] and [
>> RTCWEB-DATA-PROTOCOL
>> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#bib-RTCWEB-DATA-PROTOCOL>
>> ]."
>>
>
>  [BD] The last sentence in 5.2, third paragraph states "The actual wire
> protocol between the peers is specified by the WebRTC DataChannel Protocol
> specification ..." . I think there should only be the [RTCWEB-DATA] should
> be referenced.
>
> [GH] Agreed.
>
>
>> 2. The reliable mode cannot ensure that data is delivered, it can just
>> make efforts. It can fail after a limited number of retransmissions and it
>> is important that implementers understand that.
>> Section 5.2, fourth paragraph, replace:
>> "A reliable channel ensures that the data is delivered at the other peer
>> through retransmissions."
>> with
>> "A reliable channel makes efforts to deliver data at the other peer
>> through limited retransmission. If these limited transmissions fail, the
>> underlying transport will be abruptly aborted."
>>
>
>  [BD] I agree we need to indicate the difference between the 'reliable'
> and 'unreliable' modes. The  [RTCWEB-DATA] protocol section 5.1 implies
> that the 'reliable' mode has *No Limit* on the number of retransmissions
> (as no limit is accepted) whilst the 'unreliable' mode has EITHER a limit
> on the number of retransmissions OR on the Maximum time for transmissions
> and retransmissions. This does not align with your proposal.
>
> [GH] I cannot find your indicated "no limit". Please clarify where you
> found it.
> Instead, earlier mail discussions have indicated that the reliable channel
> SHOULD use the default parameters for SCTP streams specified in SCTP RFC
> 4960, which says:
> -----------------------------------------------copy from RFC
> 4960--------------------------------------------------------------------------------------"
>
>
> 15.  Suggested SCTP Protocol Parameter Values
>
>    The following protocol parameters are RECOMMENDED:
>
>       RTO.Initial - 3 seconds
>       RTO.Min - 1 second
>       RTO.Max - 60 seconds
>       Max.Burst - 4
>       RTO.Alpha - 1/8
>       RTO.Beta - 1/4
>       Valid.Cookie.Life - 60 seconds
>       Association.Max.Retrans - 10 attempts
>       Path.Max.Retrans - 5 attempts (per destination address)
>       Max.Init.Retransmits - 8 attempts
>       HB.interval - 30 seconds
>       HB.Max.Burst - 1
> -----------end of copy from RFC 4690------------------------------------------------------"
>
> The Path.Max.Retrans=5 is supposed to be the default limit for the number of retransmissions on WebRTC reliable data channels, and these retransmissions will normally be spread over 15 seconds before the Association is aborted with error.
>
>
>
>
>
>  I do not think that the 'No Limit' mode is practical - in real use.
> Needs more thought to align WebRTC 1.0 with [RTCWEB-DATA] and SCTP reality
> !!!
>
> [GH]Right. The 5 retransmissions over 15 seconds is practical, even if it
> introduces a risk for stalling the channel in bad network situations.
>
>
> 3. What happens when unreliable transmission fails need to be explained in
> section 5.2, fourth paragraph.
>  After the last sentence in paragraph four in 5.2, insert:
> "If the limit for the unreliable transport is exhausted for a message to
> be transmitted, the transmission of the corresponding message is aborted.
> All kinds of channels may get their underlying transport abruptly aborted
> by *the* failure *of* connectivity checks by the underlying transport."
>
> 4. The ordered characteristics is not mentioned in the introduction in
> section 5.2.
> Since the other characteristics are mentioned, I suggest that also
> ordered/unordered is introduced in a new paragraph, after the fourth
> paragraph in 5.2.
> "A RTCDataChannel
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel> can
> be configured to operate in ordered or unordered mode. In (ordered) mode,
> transmitted messages are delivered in order. Both reliable and unreliable
> channels may be set to either of these ordered/unordered modes. Ordered
> mode is the default."
>
> 5. After point 6 in the second numbered list in section 5.2, I suggest to
> introduce a brief description of that the transport can be aborted in case
> of transmission errors.
> Insert:
> "An RTCDataChannel
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>
> object's underlying data transport
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>
>  may be torn down in an abrupt manner by transmission errors. When that
> happens the user agent *must*, queue a task that sets the object's
> readyState
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel-readystate>
>  attribute to closing. This will eventually render the data transport
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>
> closed
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed>."
>
> Please verify that this is what is supposed to happen!
>
>
> 6. In chapter 11, the error event in the first table needs an explanation.
>
> Replace "TODO" in the third column for the error event the following:
> "The RTCDataChannel
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>
> object's underlying data transport
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>
>  has detected an error that caused the transport to be aborted".
>
> 7. Consider introducing an error event also for transmission failures in
> unreliable channels.
> The change proposals above do not include any error indication when
> transmission of messages in unreliable channels fail because of exhausted
> retries.
> The ambition is that WebRTC shall be as equivalent as possible to the
> Websocket API.  The Websocket API has however not specified any unreliable
> mode, so we are free to specify what happens on transmission errors on
> unreliable channels. A suitable result of a transmission error is to issue
> an error event but not abort the transport.  Note however that *SCTP*
> Watchdog failure and failure of transmission in reliable channels will
> abort the transport also for the unreliable channels using that transport
> (=RTSP association).
>
> Text proposal TBD.
>
>  [BD] NOTE - WebRTC 1.0 does NOT reference SCTP so text should either NOT
> refer to SCTP OR SCTP Reference needs to be added if text relating to SCTP
> is added later.
>
> [GH] Right. No 7 was discussion. But I would like to see it materialize in
> description of failure indications also for transmission failures in
> unreliable channels.
>
>
> Regards
>
> Gunnar
> = = = = = = = = = = = = = = =
>
>  *[BD] Additional Changes - *
>
>  There can be confusion between the functions of [RTCWEB-DATA
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#bib-RTCWEB-DATA>] and [
> RTCWEB-DATA-PROTOCOL
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#bib-RTCWEB-DATA-PROTOCOL>].
> [RTCWEB-DATA] refers to the "WebRTC Data Channels" protocol whilst the
> [RTCWEB-DATA-PROTOCOL] refers to the "WebRTC Data Channel Establishment
> Protocol".
>
> I suggest that, in the *B.References section*, we use the term
> [RTCWEB-DATA-ESTABLISHMENT] instead of [RTCWEB-DATA-PROTOCOL] and that the
> correct names of the two protocols be used in the Reference text.
>
> In addition, as the IETF uses the name "WebRTC" in the title of each
> protocol, so should we change the Reference Names to  [*WEBRTC*-DATA] and
> [*WEBRTC*-DATA-ESTABLISHMENT]
>
> [GH] I agree.
>
>   ???
>
>   ------------------------------
> Gunnar Hellström
> Omnitor
> gunnar.hellstrom@omnitor.se
>  On 2014-03-03 15:57, Michael Tuexen wrote:
>
>>  On 04 Feb 2014, at 19:40, Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> <gunnar.hellstrom@omnitor.se> wrote:
>>
>>
>>  On 2014-02-04 18:41, Martin Thomson wrote:
>>
>>  On 4 February 2014 03:52, Adam Bergkvist <adam.bergkvist@ericsson.com> <adam.bergkvist@ericsson.com> wrote:
>>
>>  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.
>>
>>  Please don't assume silence == acceptance.  I'd prefer silence ==
>> ambivalence, or maybe silence == no thanks.
>>
>> The proposed text is correct in part and too specific elsewhere.  I
>> agree with the note that reliable is instead equated with maximum
>> retry {count + time}.  I don't agree with setting specific numbers on
>> this, unless they are minimum requirements for support.
>>
>>  A follow-up question:
>>
>> If an application opens a data channel and requests the unreliable type with maximum 7 retries.
>> And it turns out that the reliable type by default makes maximum 5 retries.
>>
>> Will the channel establishment then accept to extend to 7 retries?
>> Or what will happen?
>>
>>  Even if you configure the SCTP_PR_SCTP_RTX parameter larger than association.max.retrans
>> the association will be aborted after association.max.retrans consecutive retransmissions.
>>
>>  It looks a bit strange to have an unreliable channel that is more reliable than the reliable one.
>>
>>  It isn't. SCTP_PR_SCTP_RTX limits the number of retransmissions, it doesn't enforce them.
>>
>>  But without documentation about the default retries for the reliable channel this situation might very well happen because the application programmer does not know the figure.
>>
>>  I think what is written inhttp://tools.ietf.org/html/draft-ietf-tsvwg-sctp-prpolicies-01
>> is clear. If not, please let me know.
>>
>> Best regards
>> Michael
>>
>>  If it is agreed that it is illogical to set the unreliable channel more reliable than the reliable one, an addition to the API could say:
>> "If the MaxRetries parameter is higher than the default maximum number of retries used for reliable channels, the channel will use the default number, but in other aspects perform as an unreliable channel (e.g. no channel disconnect after exceeded number of retries)."
>>
>>  That would meet your view that the proposed text had too much detail, but it covers a logical gap in the API specification.
>>
>> Gunnar
>>
>>
>>
>>
>>
>>
>
>