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

[Gunnar Hellstrom <[e-mail]>]

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.
>> 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?)

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 get any 
notification about that or if they need to introduce sequence number 
checking themselves if they are interested to know.



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? )

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 retransmissions or transmission time is exceeded in a partially 
reliable channel, the transmission SHALL be allowed to continue with 
next data item.

If reception out-of order is detected from an SCTP channel for which 
ordered transmission is requested, the receiver SHALL close the data 
channel.

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.

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