Re: [rtcweb] WGLC for data channel drafts - missing descriptions of error situations

[Gunnar Hellstrom <[e-mail]>]

The w3c API specification is still very vague about error situations and 
how they are discovered and signaled. But there are some indications 
that it expects the rtcweb-data-protocol or rtcweb-data-channel 
specification to provide details.

In the API specification of the send() method at
http://dev.w3.org/2011/webrtc/editor/webrtc.html#dictionary-rtcdatachannelinit-members

Action point 5 under send() , it says:

"5. Attempt to senddataonchannel'sunderlying data transport 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>; 
if the data cannot be sent, e.g. because it would need to be buffered 
but the buffer is full, the user agent/must/abruptly close 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed>channel'sunderlying 
data transport 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>with 
an error 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed-error>."

The buffer-full reason for failure described is just an example. This 
opens for other reasons of failure. I think the rtcweb drafts should 
specify the reasons for failure that are under their control, (and the 
text in the API spec improved to give a better view of what reasons for 
failure there are. )

There is also an anomaly in the sentence. It says that " if the data 
cannot be sent, the user agent/must/abruptly close 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#data-transport-closed>channel'sunderlying 
data transport. 
<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport>
You say that if the channel is specified as partially reliable, failures 
to send will not be signaled and the channel will not be closed. These 
statements contradict each other. For this case, it might be the wording 
in the API specification that needs to be improved and specify that " if 
the channel was specified as reliable and the data cannot be sent.....".
But knowledge about what is expected from the channel and the 
association is needed to be able to specify this correctly.

I see a clear need for the rtcweb data channel specifications to specify 
the failure situations under their control or signaled by underlying 
transport.
Please use the new section 6.7 I provided as a proposal in this thread 
and refine it from your knowledge about the real behavior.

Regards

Gunnar




------------------------------------------------------------------------
Gunnar Hellström
Omnitor
[e-mail] 2014-07-08 00:39, Gunnar Hellstrom wrote:
> Thaks Michael,
> You provide important additional information added to the section 6.7  
> on transmission failure handling for the data-channel draft that I 
> proposed below. I cannot find this information anywhere else, so I 
> think it is important to provide it in the data-channel draft so that 
> the W3C API authors can see what mechanisms are available and describe 
> the API from that.
>
> You say that the association breaks if a number of retries fail. But 
> cannot the association contain both reliable and partially reliable 
> channels? How would the decision logic to break the association 
> because a number of failures be formed when there are different kinds 
> of channels in the association? Or do I remember wrongly? Is there 
> only one type of channels in an association.
>
> You also say that both missed heartbeats and broken ICE connections 
> may break the association. Where do you suggest that that combined 
> behavior should be described? Also in the data-channel draft?
>
> Thaks,
>
> Gunnar
>
>
>
>
> ------------------------------------------------------------------------
> Gunnar Hellström
> Omnitor
> [e-mail]
> [phone]
> On 2014-07-07 22:00, Michael Tuexen wrote:
>> On 05 Jul 2014, at 08:14, Gunnar Hellstrom<[e-mail]>  wrote:
>>
>>> On 2014-07-04 23:34, Michael Tuexen wrote:
>>>> On 04 Jul 2014, at 23:23, Gunnar Hellstrom<[e-mail]>  wrote:
>>>>
>>>>> I cannot find that what happens in transmission error situations is described in any of these drafts.
>>>>>
>>>>> Both reliable and partially reliable transmission can fail, and the application designer need to know what happens.
>>>> I don't understand the notion of "reliable and partially reliable transmission can fail"...
>>>> If a user message gets abandoned (so the stack gives up transmitting/retransmitting it, but
>>>> the association stays alive), I don't think it is signalled via the JS API, but that might
>>>> be an issue of W3C. If the association fails, all data channel fail. This is signalled.
>>>> However, this is something for the W3C document.
>>> The W3C mechanism makes use of the rtcweb-data-channel.
>>> The rtcweb-data-channel should tell what happens in error situations and if that is possible to be signaled to higher layers.
>>> The higher layers should have specified the requirements on the data-channel.
>>> If no requirements can be found, we should either propose behavior in error situations or request to get requirements stated from upper layers.
>> SCTP tells the user if the association has failed. At that point all data channels
>> must be closed. But I think this is something which needs to be stated in the
>> W3C document...
>>>>> We discussed it earlier, and came to the conclusion that
>>>>> A failing reliable channel will tear down the connection and some indication will be provided if possible to the application.
>>>>> A failing partially reliable channel will enable transmission of next data item. ( I do not remember if the application will get any error indication or if it needs to have its own sequence checking if it is interested in knowing if there are no gaps. )
>>>>>
>>>>> I suggest that a section on failure handling is added. I get the impression that it is in the data-channel draft it would be best suited.
>>>> But this is about the API. So it should go into the W3C document.
>>> The API can only provide the functions provided by the mechanisms it has underneath.
>>>
>>> There was a mail discussion in webRTC about the error situations.
>>> A conclusion was that if a reliable channel reaches its retry limit ( that is usually only about 5 for WebRTC) or some other indication that the channel failed to convey the data, then the channel shall be broken (by the channel) and indications provided to both sides if possible. (another reasons mentioned was missed heartbeats for the whole association, setting a retry time limit of - what was it - - - 15 seconds?)
>> A reliable channel doesn't have a limit. The association has. If the association breaks,
>> all data channels are gone.
>>> If the retries or retransmission time is exceeded for a partially reliable channel, the conclusion was that communication can continue with next data item. I am not sure if the applications were to
>> It will continue. It is not a stop and wait...
>>> get any notification about that or if they need to introduce sequence number checking themselves if they are interested to know.
>> I don't think so. I don't see anything in the JS API.
>>>
>>> I cannot see how we can avoid describing the mechanisms needed and what happens to the channel.
>>>
>>>
>>> I found a sentence about this  in section 6.6 of the data-channel-11 draft.
>>>
>>> "
>>>
>>> If a message with an unsupported PPID is received or some error is
>>>   detected by the receiver (for example, illegal ordering), the
>>>   receiver SHOULD close the corresponding data channel."
>>>
>>>
>>> This paragraph could be extended to tell more about error situations in open channels.
>>> I suggest to move this sentence to a new section and add description of other situations. The sentence only tells about errors detected at the receiving end. But it can also be the transmitting end that detects the problem. It should be stated what shall be done then.T
>>>
>>> Something like this ( with my questions in paranthesis).
>>> -------------------------------------------------------Proposed error handling section in rtcweb-data-channel---------------------------------------------------------------------------
>>> 6.7 Transmission failure and error handling
>>> Failures can occur when a data channel is open.
>>>
>>> If transmission in a reliable channel fails, the channel shall be closed by the party detecting the failure and an error indication provided.      ( what does STCP do in this situation? )
>> This can't happen. Only the association can fail and in this case all data channels are gone...
>>> If a watchdog times out, the channel shall be closed with an error indication.         ( if this is part of the channel mechanisms, I have not seen where it is defined.)
>> If you think about SCTP HEARTBEATs, it is like the above. But it is more likely
>> that ICE will detect it first.
>>> If retransmissions or transmission time is exceeded in a partially reliable channel, the transmission SHALL be allowed to continue with next data item.
>> It is not stop and wait... next item might be transmitted before the message is abandoned.
>>> If reception out-of order is detected from an SCTP channel for which ordered transmission is requested, the receiver SHALL close the data channel.
>> This is covered by the text cited above.
>>> If a message with an unsupported PPID is received or some logical error is detected by the receiver, the receiver SHALL close the corresponding data channel.
>> This is covered by the text cited above.
>>
>> So I think the only thing not covered is what to do if the SCTP association fails,
>> but it is obvious to me that all channels are gone. Do we need to state that
>> explicitly? What do others think?
>>
>> Best regards
>> Michael
>>> --------------------End of proposed section on failure handling---------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>>
>>> Regards
>>>
>>> /Gunnar
>>>
>>>> Best regards
>>>> Michael
>>>>> Regards
>>>>>
>>>>> Gunnar
>>>>> Gunnar Hellström
>>>>> Omnitor
>>>>> [e-mail]
>>>>> On 2014-06-10 20:52, Ted Hardie wrote:
>>>>>> Dear WG,
>>>>>>
>>>>>> This starts a working group last call for our core Data Channel drafts:
>>>>>>
>>>>>> draft-ietf-rtcweb-data-protocol-06.txt
>>>>>> draft-ietf-rtcweb-data-channel-10.txt
>>>>>>
>>>>>> Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.
>>>>>>
>>>>>> Ted, Sean, Cullen
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> rtcweb mailing list
>>>>>>
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>> _______________________________________________
>>>>> rtcweb mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb