Code change:
5.8.2. <del> Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </del> <ins> The configuration of timer settings varies with implementations and certain deployment environments require timer value adjustments. Mishandling of the timer can lead to serious congestion problems, for example if many instances of a DTLS time out early and retransmit too quickly on a congested link.  Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 RFC6298) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum).  Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values.  Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time-sensitive applications.  Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. </ins> Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted,

Related discussion:
text: However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. Note that alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. [BA] For the fatal alert case, it does seem like retransmission would be a good idea; otherwise the peer can be left hanging. Section 7.1 "Disruptions" such as reordering do not affect timers, correct? ACKs SHOULD NOT be sent for these flights unless generating the responding flight takes significant time. What is "significant time"? Editorial Comments (NITs) Section 2 The reader is also as to be familiar with [BA] "as" -> "assumed" Section 3 The basic design philosophy of DTLS is to construct "TLS over datagram transport". Datagram transport does not require nor provide reliable or in-order delivery of data. The DTLS protocol preserves this property for application data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. [BA] While low-latency streaming and gaming does use DTLS to protect data (e.g. for protection of WebRTC data channel), telephony and RTC Audio/Video uses DTLS/SRTP for key derivation only, and SRTP for protection of data. So you might want to make a distinction. Section 3.1 Note that timeout and retransmission do not apply to the HelloRetryRequest since this would require creating state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests. [BA] I would add "For more detail on timeouts and retransmission, see Section 5.8." Transport Layer Mapping DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS record MUST fit within a single datagram.