From ec91df6dab2cecf77a891fa2cb6f8e831cfa35fb Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 16 Feb 2024 21:35:28 +0100 Subject: [PATCH 1/3] timers and ACKs Fix #13 Fix #18 Signed-off-by: Thomas Fossati --- draft-ietf-uta-tls13-iot-profile.md | 38 +++++++++++++++++++++++++---- 1 file changed, 33 insertions(+), 5 deletions(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 1e651a8..3398bf4 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -46,6 +46,14 @@ author: organization: "Sandelman Software Works" email: mcr+ietf@sandelman.ca +contributor: + - + ins: J. Sosinowicz + name: Juliusz Sosinowicz + - + ins: A. Kraus + name: Achim Kraus + normative: DTLS13: RFC9147 TLS13: RFC8446 @@ -200,11 +208,27 @@ negotiated independently. The discussion in Section 10 of {{!RFC7925}} is applicable. -# Timeouts +# Timers and ACKs + +Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS 1.3 ACKs sensibly decrease the risk of congestion collapse which was the basis for the very conservative recommendations given in Section 11 of {{!RFC7925}}. + +In general, the recommendations in {{Section 7.3 of DTLS13}} regarding ACKs apply. +In particular, "[w]hen DTLS 1.3 is used in deployments with lossy networks, such as low-power, long-range radio networks as well as low-power mesh networks, the use of ACKs is recommended" to signal any sign of disruption or lack of progress. +This allows for selective or early retransmission, which leads to more efficient use of bandwidth and memory resources. + +Due to the vast range of network technologies used in IoT deployments, from wired LAN to GSM-SMS, it's not possible to provide a universal recommendation for an initial timeout. +Therefore, it is RECOMMENDED that DTLS 1.3 implementations provide a way for their users to explicitly set the initial timer value. +Users SHOULD set the initial timeout to be twice the expected RTT but no less than 1000 ms. +A sub-second initial timeout MAY be set for specific application/network combinations +If no RTT estimates are available, 1 second is a good recommendation for the general internet. + +Therefore, it is RECOMMENDED that DTLS 1.3 implementations allow users to explicitly set the initial timer value. +Users SHOULD set the initial timeout to be twice the expected round-trip time (RTT), but no less than 1000ms. +For specific application/network combinations, a sub-second initial timeout MAY be set. +In cases where no RTT estimates are available, a 1 second initial timeout is suitable for the general Internet. -The recommendation in Section 11 of {{!RFC7925}} is applicable. In particular -this document RECOMMENDED to use an initial timer value of 9 seconds with -exponential back off up to no less then 60 seconds. +For RRC, the recommendations in {{Section 7.5 of !I-D.ietf-tls-dtls-rrc}} apply. +Just like the handshake initial timers, it is RECOMMENDED that DTLS 1.2 and 1.3 implementations offer an option for their users to explicitly set the RRC timer. # Random Number Generation @@ -750,4 +774,8 @@ This document makes no requests to IANA. # Acknowledgments {:unnumbered} -We would like to thank Ben Kaduk, Hendrik Brockhaus, John Mattsson and Michael Richardson. +We would like to thank +Ben Kaduk, +Hendrik Brockhaus, +and +John Mattsson. From 4c874eff31cdbc8161e6ef92dda3917cfb32043e Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Sat, 17 Feb 2024 07:37:49 +0100 Subject: [PATCH 2/3] remove dup block --- draft-ietf-uta-tls13-iot-profile.md | 5 ----- 1 file changed, 5 deletions(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 3398bf4..1a5c930 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -217,11 +217,6 @@ In particular, "[w]hen DTLS 1.3 is used in deployments with lossy networks, such This allows for selective or early retransmission, which leads to more efficient use of bandwidth and memory resources. Due to the vast range of network technologies used in IoT deployments, from wired LAN to GSM-SMS, it's not possible to provide a universal recommendation for an initial timeout. -Therefore, it is RECOMMENDED that DTLS 1.3 implementations provide a way for their users to explicitly set the initial timer value. -Users SHOULD set the initial timeout to be twice the expected RTT but no less than 1000 ms. -A sub-second initial timeout MAY be set for specific application/network combinations -If no RTT estimates are available, 1 second is a good recommendation for the general internet. - Therefore, it is RECOMMENDED that DTLS 1.3 implementations allow users to explicitly set the initial timer value. Users SHOULD set the initial timeout to be twice the expected round-trip time (RTT), but no less than 1000ms. For specific application/network combinations, a sub-second initial timeout MAY be set. From 1dedc23b1c1765c0487961b80f2ad6b23fe7d6ba Mon Sep 17 00:00:00 2001 From: Thomas Fossati Date: Fri, 23 Feb 2024 13:40:53 +0100 Subject: [PATCH 3/3] use fancier refs --- draft-ietf-uta-tls13-iot-profile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-uta-tls13-iot-profile.md b/draft-ietf-uta-tls13-iot-profile.md index 1a5c930..db16514 100644 --- a/draft-ietf-uta-tls13-iot-profile.md +++ b/draft-ietf-uta-tls13-iot-profile.md @@ -210,7 +210,7 @@ The discussion in Section 10 of {{!RFC7925}} is applicable. # Timers and ACKs -Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS 1.3 ACKs sensibly decrease the risk of congestion collapse which was the basis for the very conservative recommendations given in Section 11 of {{!RFC7925}}. +Compared to DTLS 1.2 timeout-based whole flight retransmission, DTLS 1.3 ACKs sensibly decrease the risk of congestion collapse which was the basis for the very conservative recommendations given in {{Section 11 of !RFC7925}}. In general, the recommendations in {{Section 7.3 of DTLS13}} regarding ACKs apply. In particular, "[w]hen DTLS 1.3 is used in deployments with lossy networks, such as low-power, long-range radio networks as well as low-power mesh networks, the use of ACKs is recommended" to signal any sign of disruption or lack of progress.