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

[Gunnar Hellstrom <[e-mail]>]

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