Should we add some language why "setup:holdconn" make very little sense for DTLS? Should we specify that it is not allowed or should we specify how it should be handled and advise to avoid it?
The "holdconn" attribute was designed to prevent the need for running "accept" like calls on connection oriented protocols, when sending offers with "connection:exisitng". For such protocols the offerer generating an offer with a connection value of 'existing' and a setup value of 'passive' needs to be ready (i.e., needs to allocate resources) to receive a connection request from the answerer just in case the answerer chooses a connection value of 'new' for the answer. However, if the answerer uses a connection value of 'existing' in the answer, the offerer would need to deallocate the previously allocated resources that were never used because no connection request was received. To avoid allocating resources unnecessarily, offerers using a connection value of 'existing' in their offers may choose to use a setup value of 'holdconn'.
In case of DTLS, offerer should be ready to process the new DTLS ClientHello on a new 5-tuple and queue it until an answer is received. This means that no additional resources are typically necessary for queuing DTLS packets before handshake is actually initiated and such packets are received. Which, in turn, means there is very little value in "setup:holdconn" in case of DTLS. In other words, since DTLS does not require a separate accept like call, that TCP requires to accept new connection requests, there are no actual resource savings due to "setup:holdconn".
Since holdconn complicates DTLS implementation for no particular benefit, and since I am not aware of any DTLS implementations that actually use it, I would suggest making this setup value invalid.
Should we add some language why "setup:holdconn" make very little sense for DTLS? Should we specify that it is not allowed or should we specify how it should be handled and advise to avoid it?
The "holdconn" attribute was designed to prevent the need for running "accept" like calls on connection oriented protocols, when sending offers with "connection:exisitng". For such protocols the offerer generating an offer with a connection value of 'existing' and a setup value of 'passive' needs to be ready (i.e., needs to allocate resources) to receive a connection request from the answerer just in case the answerer chooses a connection value of 'new' for the answer. However, if the answerer uses a connection value of 'existing' in the answer, the offerer would need to deallocate the previously allocated resources that were never used because no connection request was received. To avoid allocating resources unnecessarily, offerers using a connection value of 'existing' in their offers may choose to use a setup value of 'holdconn'.
In case of DTLS, offerer should be ready to process the new DTLS ClientHello on a new 5-tuple and queue it until an answer is received. This means that no additional resources are typically necessary for queuing DTLS packets before handshake is actually initiated and such packets are received. Which, in turn, means there is very little value in "setup:holdconn" in case of DTLS. In other words, since DTLS does not require a separate accept like call, that TCP requires to accept new connection requests, there are no actual resource savings due to "setup:holdconn".
Since holdconn complicates DTLS implementation for no particular benefit, and since I am not aware of any DTLS implementations that actually use it, I would suggest making this setup value invalid.