search

thomas-fossati / draft-tls13-iot

Other
0 stars 1 forks source link

DTLS 1.3: What should the retransmission timer recommendation be? #13

Closed hannestschofenig closed 9 months ago

hannestschofenig commented 3 years ago

RFC 7925 RECOMMENDs a very high (9s) initial RTO for DTLS 1.2 handshake

Reasons:

  1. to avoid spurious retransmits when the public key operation is taking long on a constrained node
  2. to avoid congestion on LLNs when the loss is genuine and the flight to retransmit is bulky (e.g., certificate) and maybe fragmented
  3. to cater for very high latency variance in certain access technology (e.g., GSM-SMS)

DTLS 1.3 now offers per-record retransmission and therefore less congestion risk on genuine loss, which makes 2. less relevant.


The question is: should we soften the initial retransmission timers recommendations for 1.3?

Options:

OR13 commented 1 year ago

Seems like one argument for keeping them would be support for whats observed in the wild.

Any evidence to rule out one or more of the options above?

thomas-fossati commented 9 months ago

See also WolfSSL's DTLS 1.3 examples. Specifically, the wolfssl_dtls13_use_quick_timeout API.

thomas-fossati commented 9 months ago

@rizlik, @julek-wolfssl: in draft-ietf-uta-tls13-iot-profile we want to make IoT-friendly recommendations for DTLS 1.3 handshake timers - similar to the work we did in RFC7925 for DTLS 1.2.

The intuition is that given the retransmission algorithm improved quite drastically in 1.3, the timers could be relaxed without risking congestion collapse. The trouble is that 1.3 implementations are quite scarce at the moment and we are struggling to get data on which to base the recommendations.

Since you worked on the implementation of DTLS 1.3 in WolfSSL, we are reaching out to you for feedback, deployment experience, etc.

TIA!

julek-wolfssl commented 9 months ago

Restoring accidentally deleted comment:

Hi @thomas-fossati, for IoT devices, we don't think that it is possible to give one uniform recommendation for an initial timeout. There exist networks with very low latency (a LAN ethernet setting) and those with very high latency (the previously mentioned GSM-SMS is a great example). We recommend that users set the initial timeout to be twice the expected RTT but no less than one second. This will allow the best optimal performance for each network.

Of course, the one second minimum timeout is also not always applicable. For some applications, one second may be an eternity and thus an even lower timeout may be used. One open source adopter of DTLS 1.3 is ExpressVPN. They use an initial timeout of 100ms (https://github.com/expressvpn/lightway-core/blob/main/src/he/conn.c#L776) to provide the best user experience. This makes the handshaking immediate even with network losses.

We agree that the explicit ACKs in DTLS 1.3, decrease the risk of congestion collapse. There are still cases where a peer will resend its entire flight (when it doesn't receive anything from the other end and the timeout is reached). This needs to be taken in consideration when estimating bandwidth use.

Quick timeouts are another great addition to DTLS 1.3. This increases latency slightly but decreases bandwidth significantly by allowing messages to arrive out of order. We follow the RFC specified timeout / 4 but this can also be tuned to fit user's working environment.

In summary: there is no one size fits all for IoT. 1 second is a good recommendation for the general internet.

Juliusz

thomas-fossati commented 9 months ago

Juliusz, thank you very much for your precious feedback. We working on incorporating it into the next version of the draft. BTW, your feedback on the document as a whole is also much appreciated :-)

julek-wolfssl commented 9 months ago

We're happy to help. We'll try to take a look at the draft this week.

thomas-fossati commented 9 months ago

We're happy to help. We'll try to take a look at the draft this week.

awesome!

julek-wolfssl commented 8 months ago

Hi @thomas-fossati , we are slowly working our way through the RFC. What is the most appropriate way to provide feedback for the draft?

thomas-fossati commented 8 months ago

Hi Juliusz,

Hi @thomas-fossati , we are slowly working our way through the RFC.

Much appreciated!

What is the most appropriate way to provide feedback for the draft?

A couple of options, in no particular order:

  1. Filing issues in this repo;
  2. Sending your comments via email to the UTA mailing list (uta@ietf.org) with "draft-ietf-uta-tls13-iot-profile" mentioned in the subject, e.g., "comments on draft-ietf-uta-tls13-iot-profile", or similar.

TIA