Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

On Apr 20, 2013, at 7:24 PM, Bernard Aboba wrote:

> (retransmitted to fix a cut-and-paste error). 
>  
> Randell said:
> 
> "Well, if we do decide to timeout or size-out buffering of unordered early data, I wouldn't do so quickly.  My example for this would be a data-only application opening an channel just as it's fading out of WiFi/cell coverage... If you want opens to timeout, that should be part of how Open works (partial-reliable with a max time), not indirectly-in-some-edge-cases like this."
>  
> [BA] I agree that it makes sense to be explicit about the transport properties desired for OPEN. There is a tradeoff between a timeout/size-out of unordered early data and the amount of "reliability" that the OPEN will really have.    For example, if the timeout is more than one and less than 3 RTOinitial, then you are effectively only allowing for the OPEN to be retransmitted once; between 3 and 7 RTOinitial, twice; between 7 and 15 RTOinitial, three times, etc.  The timeout also limits the amount of time that the endpoint can be out of coverage in the case you gave. In terms of buffering, there are similar implications.  The amount of buffer allocated will determine how many times the OPEN can be retransmitted.  To be resilient, I wouldn't recommend a max time of less than 15 seconds, and one could argue for 30 seconds or more (e.g. the potential effect of routing transients). 
SCTP provides already mechanisms to determine that the connectivity os lost and the SCTP
association is terminated. The parameter to control this is the number of consecutive timer-based
retransmissions. Why not just make use of these mechanisms.

Best regards
Michael
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb