DTLS minimum handshake timeout

[samuel4]

Hi

It seems that the default minium DTLS handshake timeout is about 1 second. That means, there is a retransmission if a response isn't received within this timeout. In NB-IoT/LTE-M this leads to many unnecessary retransmission:

The server is configured to a higher timeout, but how can I configure the nRF9151 to be more patient during handshake? Since NB-IoT has latencies up to 10 seconds, retransmitting every second does barely make sense.

I have tried a lot of socket options so far, but none seem to work. Zephyr itself offers TLS_DTLS_HANDSHAKE_TIMEOUT_MIN, but this one is not supported on offloaded sockets. Am I missing something? It would be a pitty if I have to switch to mbedTLS, because of a missing handshake timeout.

NCS version: v3.0.2

Best regards
Samuel

[Achim Kraus]

I missed one important point about the start of the timeout:

For the initial communication, it works fine to send the first message after the network registration.

But for "follow up messages" during PSM sleep, it's changing. Here it takes from 0.5s up to 10s (and more, especially for NB-IoT) to be able to transmit the message. If then a new handshake gets required, the timeouts needs to consider that. Otherwise it just "queues" the Client_Hello and flash them after getting connected.

[samuel4]

Agreed, I will look into this, too. Right now, I focus on the first handshake after the modem is registered to network.

To ensure, we're all talking about the same: Here is the DTLS RFC about the retransmission scheme:

https://datatracker.ietf.org/doc/html/rfc6347#section-4.2.4.1

They suggest a initial handshake timeout of 1 second "in order to improve latency for time-sensitive applications". However that's barely the case in NB-IoT. I don't think it's a good choice at the nRF91. Because of this short timeout I see avoidable retransmission on almost every handshake.

 Øyvind Could you check if I missed such a socket open etc. or if you plan to implement it? The best solution in my point of view would be implementing the existing zephyr socket options:

BSD Sockets — Zephyr Project Documentation

Best regards
Samuel

[Øyvind]

Hi Samuel, I have forwarded this discussion internally and will update as soon as I have more feedback.

Kind regards,
Øyvind

[Øyvind]

Hello again, 

our team informs me that due to high work load and vacation time they are not able to provide an answer to you until work week 32. 

Will get back to you when we have an answer.

Kind regards,
Øyvind

[Achim Kraus]

samuel4 said:

To ensure, we're all talking about the same: Here is the DTLS RFC about the retransmission scheme:

Yes, that's the timer values I'm talking about. But, I'm not a developer of mbedtls nor a Nordic employee, but I'm the project lead of eclipse/californium and I implemented the retransmission mechanism and configuration for Californium/Scandium. Mainly as outcome of some first NB-IoT experience a couple of years ago. I'm also a committer of Eclipse/tinydtls and so I use that for my own zephyr client in order to adjust the timers in a way adapted for NB-IoT.

About mbedtls there may be others more common and experienced, I just checked the mbedtls examples and that points to "void mbedtls_ssl_conf_handshake_timeout(mbedtls_ssl_config *conf, uint32_t min, uint32_t max);".