Re: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-06 - SCTP parameters and options

[Gunnar Hellstrom <[e-mail]>]

There is a set of parameters for SCTP in RFC 4690 with proposed values 
in chapter 15.

I suggest that the data-channel draft specifies somewhere that the 
values recommended in SCTP chapter 15 SHOULD be used whenever there is 
no reason to select other values.

The following is an extract from SCTP chapter 15:
15 <http://tools.ietf.org/html/rfc4960#section-15>. Suggested SCTP 
Protocol Parameter Values



    The following protocol parameters are RECOMMENDED:

       RTO.Initial - 3 seconds
       RTO.Min - 1 second
       RTO.Max - 60 seconds
       Max.Burst - 4
       RTO.Alpha - 1/8
       RTO.Beta - 1/4
       Valid.Cookie.Life - 60 seconds
       Association.Max.Retrans - 10 attempts
       Path.Max.Retrans - 5 attempts (per destination address)
       Max.Init.Retransmits - 8 attempts
       HB.interval - 30 seconds
       HB.Max.Burst - 1

-------------------------

Some of them are for example used in chapter 8, fault management, where 
also some of my earlier questions are touched.

This is my deduction of a typical error scenario:

The retry mechanism seems to possibly result in retries after about 1, 
3, 7, 15 and 31 seconds after the initial transmission of a chunk of 
data. If still not successful, the path is considered to fail. If no 
other path is available, the connection fails.  ( this assumes a 
connection with about <400  ms delay )



SCTP is not totally clear about if the upper layer shall be told about 
the failure.

In 8.2 it says:

When the value in the error counter exceeds the protocol parameter
    'Path.Max.Retrans' of that destination address, the endpoint should
    mark the destination transport address as inactive, and a
    notification SHOULD be sent to the upper layer.


(There are other cases in 8.1 with even more vague requirement to report 
the failure to the upper layer. )


I suggest that the data channel draft shall be clear about that the 
higher layer gets an error indication, indicating how much data the 
sending side has marked as unsent.


The retries for the partially-reliable channel type seems to only have 
any meaning if it is set to a value <5
The retry time for the partially-reliable channel will also have an 
upper liit set by the maximum retry period for the reliable channel, but 
it is harder to peredict what the limits are.  31 seconds seems to be 
one of the shortest total retry periods appearing, so times <30 s makes 
sense as partially-reliable total retry timeout.


Gunnar



------------------------------------------------------------------------

[e-mail]

On 2013-12-16 21:48, Gunnar Hellstrom 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.
> 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.
> 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?
>
> Not until that is known, it can be judged if a reliable or 
> partially-reliable channel is the right choice for the planned 
> application.
>
>
>>
>>> 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.
>
>
>
> /Gunnar
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>