Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Bernard Aboba <[e-mail]>]

(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).