DTLS 1.2 over high-latency NB-IoT links

[humfry]

Hello,

We are using bctls-jdk18on 1.86.1 for a DTLS 1.2 server in a large NB-IoT deployment (several 100k devices).

Typical RTT is below 500ms, but for about 5-10% of devices we see RTTs up to 40 seconds.

We observe that DTLS handshake retransmissions occur well before a valid response can arrive on these high-latency links.

Before modifying BC internals, I would like to understand whether there is a supported way to configure DTLS retransmission behaviour (initial timeout, backoff strategy, retransmission count, handshake timeout).

What would be the recommended approach?

Any guidance would be appreciated.

Best regards

[dfbustosus]

There is a supported way to tune the two relevant timers without modifying BC internals. Override the TlsPeer methods in your TlsServer implementation, for example:

@Override
public int getHandshakeResendTimeMillis() {
    return 45_000;
}

@Override
public int getHandshakeTimeoutMillis() {
    return 180_000;
}

getHandshakeResendTimeMillis() controls the initial DTLS retransmission interval. BC then doubles that interval after each retransmission, capped at 60 seconds. getHandshakeTimeoutMillis() limits the complete handshake; its default value of 0 means unlimited.

For a measured tail RTT near 40 seconds, I would start with an initial interval slightly above that tail, then tune it from production measurements. At this deployment scale, a finite total handshake timeout is also important so unreachable clients do not retain server state indefinitely.

There is no public API for an explicit retransmission count or for replacing the exponential-backoff strategy. Those details are internal to DTLSReliableHandshake, so changing them would require a BC change rather than server configuration.

Relevant source: TlsPeer timeout API, AbstractTlsPeer defaults, and DTLSReliableHandshake backoff.