Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06

[Michael Tuexen <[e-mail]>]

On Dec 28, 2013, at 5:07 PM, Gunnar Hellstrom <[e-mail]> wrote:

> Thanks Michael for good clarifications.
> 
> You are right that the part of the discussions about API-only considerations need to be taken in the webrtc list in W3C.
> But the data channel and the SCTP implementation and parameters need to be specified clearly enough for the API to be able to deliver its specified characteristics.
> 
> So, I hope that some of the details discussed here will show up as details in  draft-ietf-rtcweb-data-channel
I think it makes sense to cover the specifics of being single homed. I'll add text to avoid the dormant state.
> 
> E.g. a chapter on failure handling, for the three types of channels: Unreliable, partially-reliable and reliable, and what happens when they encounter transmission failures.
If the association fails, all data channels fail. It doesn't matter if they are ordered or not,
reliable or not. That is pretty simple. A data channel can't fail (except for a peer violating
the protocol) without all other data channels belonging to the same association also failing.
Do you think that this should me mentioned?

Best regards
Michael
> 
> /Gunnar
> On 2013-12-28 12:42, Michael Tuexen wrote:
>> On Dec 16, 2013, at 9:48 PM, Gunnar Hellstrom <[e-mail]> wrote:
>> 
>>> On 2013-12-16 10:12, Harald Alvestrand wrote:
>>>> On 12/15/2013 11:25 PM, Gunnar Hellstrom wrote:
>>>>> I took a look at the data channel draft.
>>>>> 
>>>>> I am missing descriptions of the requirements of how transmission
>>>>> failures are to be handled.
>>>>> 
>>>>> I suggest that section   6.6 "Transferring User Data on a Channel" is
>>>>> extended with a description on what happens if the transmission fails.
>>>>> It is evident that there will be different actions for the different
>>>>> types of channels.
>>>>> 
>>>>> For unordered, unreliable channels, I assume that neither the
>>>>> transmitter nor the receiver will be notified of transmission failures.
>>>>> 
>>>>> For ordered, semi-reliable channels, I assume that the transmitter is
>>>>> notified about failure if the transmitting channel has no indication
>>>>> of successful transmission after the specified number of
>>>>> retransmissions or milliseconds.
>>>>> Same with the receiver, but the error notification may not appear
>>>>> until next transmission is received, so that the gap can be detected.
>>>>> 
>>>>> Also the so called ordered reliable channel may fail. It just has a
>>>>> higher number of retries over a longer time. So, same information
>>>>> should be provided for that type.
>>>> The traditional way of signalling the failiure of a reliable channel is
>>>> to indicate that the channel has failed.
>>> So, let us try to get proposed text in order for a suitable behavior for the data channel draft.
>>> 
>>> In the data channel draft, section 6.6, I suggest to add something like:
>>> --------------------------------------------------------------
>>> "In case of transmission problems, a reliable channel and a partially-reliable channel performs retries. The retries for a reliable channel are limited by SCTP parameters. The retries for a partially-reliable channel are limited by the parameter set by the application at channel creation time.
>>> 
>>> If transmission on a reliable channel is considered unsuccessful by the transport protocol, the channel is regarded to have failed. An error report is provided to the upper layer on the transmitter side. An error report is provided on the  receiver side if the receiver has any indication that a transmission was intended.
>> Please note that not only the channel fails, but all channels using the same SCTP association.
>> Since a peer connection currently uses a single SCTP association, this means all data channel
>> of that peer connection fail.
>>> If the channel is ordered, then no data from the lost transmission and onwards is lost.
>>> 
>>> If transmission on a partially-reliable channel is unsuccessful after the specified retry limit, the channel reports temporary failure to the transmitting application and accepts new send requests. If the channel is un-ordered, the receiving side will not notify the application about the loss.
>> I think you are discussion API issues here. I think they are not discussed within the IETF...
>> However, SCTP can provide on the sender side a notification that some use message has been
>> abandoned.
>>> If the channel is ordered, then the channel on the receive side provides a loss indication in place of the lost data.
>>> 
>>> If transmission on a nonreliable channel is unsuccessful, it is not reported as any failure."
>>> 
>>> -------------------------------------------------------------
>>> It could also be collected in a separate section "Data transmission failures" after section 6.6.
>>> 
>>> Further thoughts:
>>> 
>>> For an application designer, it is important to know for how long the channel will stall in case of transmission problems before it is regarded to have failed. I could not find information for the general case in SCTP.
>>> Can anyone guide on this: How long does SCTP try with a reliable transmission before it gives up?
>> It is the association maximum transmit counter. However, some implementation fail the association
>> if it goes into the dormant state, which means that all paths are inactive.
>>> Not until that is known, it can be judged if a reliable or partially-reliable channel is the right choice for the planned application.
>> Reliable means, that all channels are taken down if a message doesn't make it through.
>> Partial reliable means, that transmission of a message can fail, the association stays up.
>>> 
>>>>> And, is there just an error notification and then open for trying next
>>>>> transmission, or is the channel broken and needs to be opened again. I
>>>>> suggest that transmission can continue after the error notification.
>>>> This should expose the corresponding property of the SCTP protocol. I
>>>> expect SCTP experts will answer that.
>>> Yes, please. I did not find it in RFC 4960.
>>>>> Can duplications be guaranteed to be avoided in the ordered channel?
>>>> As far as I know, yes.
>>>> 
>>>>> Can there be cases when the transmitter gets a notification about
>>>>> failure, but the receiver has received the data successfully?
>>>> Yes. Avoiding such a situation is logically impossible; you'd get into
>>>> an infinite regression of ACKs otherwise.
>>>> 
>>>>> How is this reflected in WebRTC API:s?
>>>> The WebRTC API has no defined function for notification of
>>>> single-message transmission failure. So it reflects the assumption that
>>>> one either gets no indication at all (for unreliable and limited-retry)
>>>> or channel failure (for reliable).
>>> This sounds not logical for ordered partially-reliable channels.  I think a gap indication shall be provided through the API.
>>> I inserted that thought for the text proposal for draft-ietf-rtcweb-data-channel-06, and something similar is needed in the API as well.
>> I think the API should be discussed in the W3C...
>> 
>> Best regards
>> Michael
>>> 
>>> 
>>> /Gunnar
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
> 
>