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

[Michael Tuexen <[e-mail]>]

On Dec 29, 2013, at 11:41 AM, Gunnar Hellstrom <[e-mail]> wrote:

> On 2013-12-28 10:45, Michael Tuexen wrote:
>> On Dec 28, 2013, at 1:03 AM, Gunnar Hellstrom <[e-mail]>
>>  wrote:
>> 
>> 
>>> 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.
>>> 
>> I'm not sure what the value of stating that is... Isn't it clear?
> Yes, maybe you are right. RFC 4960 chapter 15 is called:
> "
> 15.  Suggested SCTP Protocol Parameter Values
> "
> 
> That sounds vague, but the first line of that chapter says:
> 
> " The following protocol parameters are RECOMMENDED:"
> 
> And according to RFC 2119, that means "
> that there
> may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
> So, yes, you are right, this is exactly what I asked for. My request can be dropped here, but some information about the resulting characteristics need instead to be described in the API specification so that developers know what they are using.
OK.
>  I have initiated that discussion in webrtc now.
Great. Thanks.

Best regards
Michael
> 
> 
>>> The following is an extract from SCTP chapter 15:
>>> 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.
>>> 
>> However, SCTP over DTLS uses a single homed setup only, so we might want to clarify Association.Max.Retrans
>> and Path.Max.Retrans. We might want to use a setting with Association.Max.Retrans = Path.Max.Retrans
>> to avoid the dormant state. Making such a statement makes sense for me.
>> 
> Yes, that is stated in a note in RFC 4960 section 8.2, but would be good to bring up more clearly in the data-channel spec. 
>>> 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 )
>>> 
>> No. You still haven't tried Association.Max.Retrans. There is the case where all
>> paths have failed, but the association hasn't yet. This is sometimes called the
>> dormant state. It is not clearly specified what to do in this state. There
>> are implementations which continue to try (the FreeBSD implementation is an example),
>> other might fail the association earlier that expected.
>> 
> But since we set Association.Max.Retrans=Path.Max.Retrans=5,  this will be the behavior. And timed out Heartbeats every 30 seconds also count in the retransmission counters. So, for all practical situations in WebRTC, the reliable channel will stall between 30 and 60 seconds and then have made 4 or 5 retransmissions of the data. If still not successful, the channel will fail.
> 
> 
>  
>>> 
>>> 
>>> SCTP is not totally clear about if the upper layer shall be told about the failure. 
>>> 
>> RFC 4960 specifies mostly the protocol on the wire. If you want an informational
>> API, please have a look at RFC 6458.
>> 
>>> 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. 
>>> 
>> That is an API issue and is, as far as I understand, discussed in the W3C.
>> 
>>> 
>>> 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.
>>> 
>> Please note that some chunk might be retransmitted more often than Association.Max.Retrans or
>> Path.Max.Retrans if the error counter gets cleared somehow. For example by successfully transmitting
>> a different chunk or a successful HEARTBEAT. In FreeBSD we limit the number of retransmissions
>> of each chunk and fail the association if that threshold is hit. This can happen, for example,
>> if small HEARTBEATs make it through the peer, but a large DATA chunk doesn't.
>> 
> I also see a risk that if the unreliable transfer mode is selected, it is said that each data chunk is sent once. But I think that there might be situations when data is never sent, if other channels get priority and are in retransmissions and reach the retransmission limit before this unreliable data chunk has been transmitted.
> Right?
>> 
>> Best regards
>> Michael
>> 
>>> 
>>> 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
>>>>>  
>>>>> 
>>> _______________________________________________
>>> rtcweb mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>