5. Use Cases

Each endpoint sends HeartbeatRequest messages at a rate and with the padding required for the particular use case. The endpoint should not expect its peer to send HeartbeatRequests. The directions are independent.

5.1. Path MTU Discovery

DTLS performs path MTU discovery as described in Section 4.1.1.1 of [RFC6347]. A detailed description of how to perform path MTU discovery is given in [RFC4821]. The necessary probe packets are the HeartbeatRequest messages.

This method of using HeartbeatRequest messages for DTLS is similar to the one for the Stream Control Transmission Protocol (SCTP) using the padding chunk (PAD-chunk) defined in [RFC4820].

5.2. Liveliness Check

Sending HeartbeatRequest messages allows the sender to make sure that it can reach the peer and the peer is alive. Even in the case of TLS/TCP, this allows a check at a much higher rate than the TCP keep-alive feature would allow.

Besides making sure that the peer is still reachable, sending HeartbeatRequest messages refreshes the NAT state of all involved NATs.

HeartbeatRequest messages SHOULD only be sent after an idle period that is at least multiple round-trip times long. This idle period SHOULD be configurable up to a period of multiple minutes and down to a period of one second. A default value for the idle period SHOULD be configurable, but it SHOULD also be tunable on a per-peer basis.