Re: RTCDataChannel characteristics and failures -API description -

On 2014-08-18 09:15, Harald Alvestrand wrote:
> On 08/16/2014 08:10 PM, Gunnar Hellstrom 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>]."
>>
>> 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."
>
> I'd rephrase this as "A reliable channel ensures that as long as the 
> transport is not aborted, the data is delivered at the other peer 
> through retransmissions".
[GH] Yes, acceptable, assuming that the reasons for transport abortion 
is well specified.
>
>>
>> 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 failure in connectivity checks by the underlying 
>> transport."
>
> Disagree with this change.
> Aborts of the whole channel are unrelated to the properties of 
> unreliable transmission.
>
> When unreliable transmission fails, the packet fails to be delivered. 
> There is no abort, and there is no signalling of this event.
Right.
But when retransmission fails in a reliable channel, the Association and 
all channels on that association will be aborted. So, retransmission 
failure on a reliable channel will take down an unreliable channel.
And then we have the failing SCTP heartbeats that will abort the 
association and all kinds of channels.

( and ICE connectivity check failures, but I assume them to be handled 
above the API level  - see a separate discussion )

So, the second sentence in my proposed text should be moved to a common 
place for describing transport layer abortion reasons.

Resulting proposal:

After last sentence 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 failure in connectivity checks by the underlying transport, 
and by retransmission failure in reliable channels in the same peer 
connection."

>>
>> 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 inordered 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."
> Text already present in paragraph 3:
>
> " Each||RTCDataChannel| 
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|has 
> an associatedunderlying data transportthat is used to transport actual 
> data to the other peer. The transport properties of theunderlying data 
> transport 
> <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>, 
> such as *in order delivery settings and reliability mode*, are 
> configured by the peer as the channel is created."
>
> Text already present in paragraph 4:
> "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 channe*l."
>
> I don't see a need to change this.
Yes, it is described in the text. But the introduction seems to briefly 
describe all aspects of the channel. If the ordered/unordered is not 
mentioned, it comes as a surprise that this feature also exists. Maybe 
no big deal, but I suggest to have it in the intro as well.
>
>>
>> 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'sunderlying 
>> 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 thedata 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!
>
> I think we're missing text for the "closing procedure" - there's 
> nothing that I can find that says what happens once the state is in 
> "closing", or what process drives it. Good catch!
>
>>
>>
>> 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'sunderlying 
>> 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.
>
> I don't think we have protocol to detect those. An unreliable channel 
> is by definition unreliable; there is no guarantee that the message is 
> *not* delivered either.
Right. The value of an indication at the transmitting side that "the 
message might not have reached the destination" is probably not 
interesting enough to introduce. So, I withdraw the proposal to get 
error indications on 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 STCP Watchdog failure and failure of 
>> transmission in reliable channels will abort the transport also for 
>> the unreliable channels using that transport (=RTSP association).
>
> RTSP?
SCTP


/Gunnar
>>
>> Text proposal TBD.
>>
>> Regards
>>
>> Gunnar
>>
>>
>> ------------------------------------------------------------------------
>> 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>  wrote:
>>>
>>>> On 2014-02-04 18:41, Martin Thomson wrote:
>>>>> On 4 February 2014 03:52, Adam Bergkvist<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 in
>>> http://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
>>>>
>>>>
>>>>
>>
>