A buoy's DTLS handshake flight is lost on a satellite uplink; what resends it, and how does the timer behave?

seniorshould knowfreq 40%

answer

the repair has to come from here
the unit is a flight
one second, then keep doubling
sixty seconds is the ceiling
keep the last flight to resend

basics

~20 s

Nothing beneath DTLS retransmits, so the sender does. DTLS groups handshake messages into flights and keeps a timer per flight: it should start at 1 second, double on each retransmission, and cap at 60 seconds, resending the entire flight each time.

solid answer

~50 s

DTLS is its own reliability layer for the handshake and nothing else. Handshake messages are grouped into flights, and a sender that has transmitted a flight starts a timer; if the peer's next flight has not arrived when it expires, the sender resends the whole flight, because in DTLS 1.2 nothing tells it which part was lost. RFC 6347 says implementations SHOULD start at 1 second — the RFC 6298 minimum — and double at each retransmission up to the 60-second maximum, resetting on progress. A peer must also keep its last flight so it can answer a retransmission it receives, since a retransmitted message from the other side implies its own flight never landed. DTLS 1.3 adds an explicit acknowledgement, content type ack(26), listing the record numbers received, so a sender can resend only what is missing.

DTLS is its own reliability layer for the handshake and nothing else. Handshake messages are grouped into **flights**, and a sender that has transmitted a flight starts a timer; if the peer's next flight has not arrived when it expires, the sender resends the **whole** flight, because in DTLS 1.2 nothing tells it which part was lost. RFC 6347 says implementations SHOULD start at 1 second — the RFC 6298 minimum — and double at each retransmission up to the 60-second maximum, resetting on progress. A peer must also keep its last flight so it can answer a retransmission it receives, since a retransmitted message from the other side implies its own flight never landed. DTLS 1.3 adds an explicit acknowledgement, content type `ack(26)`, listing the record numbers received, so a sender can resend only what is missing.

code

pseudocode · 17 lines

pseudocode

timeout = 1 second                      -- the RFC 6298 minimum
send flight
retain flight so it can be sent again

repeat:
  wait for the peer's next flight until timeout expires

  if the peer's flight arrives:
      timeout = 1 second                -- progress, so reset
      send the next flight

  if a retransmitted message from the peer arrives:
      resend the retained flight        -- the peer never got it

  otherwise (timer expired):
      resend the retained flight in full
      timeout = minimum(timeout x 2, 60 seconds)

go deeper

for a junior

Know that DTLS has to repair its own handshake because nothing below it will, and that it resends on a timer that backs off rather than retrying at a fixed rate.

for a middle

Explain the unit and the schedule: flights rather than messages, a timer that should start at 1 second and double to a 60-second maximum, and a reset when the exchange makes progress.

for a senior

Bring the operational edges: an application connect timeout shorter than the backoff kills viable handshakes, the last flight must be retained to answer a peer's retransmission, and repeated identical flights point at one-directional loss.

for a principal

Treat the backoff as fleet policy. It is what stops many devices that lost the same flight from synchronising into a retry storm, and it sets the floor for connect budgets and radio duty cycles across the estate.

Nobody underneath is going to do it

Over a stream, a lost handshake message is repaired below TLS and the handshake layer never learns of it. Over datagrams there is no such layer, so DTLS has to detect loss and repair it itself — but only for the handshake. Once the handshake completes, the reliability machinery stops and application records take their chances.

Flights, not messages

DTLS groups the handshake into flights: the contiguous run of messages one side sends before it must wait for the other. A client's opening flight is its ClientHello; a server's reply flight in a full handshake carries its hello and its certificate messages through to the end of its turn.

The unit of retransmission is the flight, not the message, and in DTLS 1.2 that is forced rather than lazy: a sender that gets no reply knows only that something in the exchange went missing. It cannot tell whether its own flight was lost, whether one fragment of it was lost, or whether the peer's answer was lost on the way back — so it resends everything it last sent.

The timer

RFC 6347 specifies the schedule as a recommendation, not a mandate, and the exact strength matters:

implementations SHOULD use an initial timer value of 1 second, which is the minimum defined by RFC 6298;
the value doubles at each retransmission, up to the RFC 6298 maximum of 60 seconds;
the timer is reset to the initial value when the exchange makes progress and the sender moves to the next flight.

So the gaps run 1, 2, 4, 8, 16, 32, 60, 60 … and a handshake on a bad link can be minutes old before it either completes or is abandoned.

Two events restart a flight, not one:

The timer expires — retransmit the flight.
A retransmitted message arrives from the peer — the peer is asking again, which means its view is that your flight never landed, so retransmit rather than wait out your own timer.

That second rule is why a peer must retain its last flight after sending it, including after the handshake appears finished: the final Finished flight may need to be sent again for a peer whose copy was lost.

What DTLS 1.3 changes

DTLS 1.3 keeps the timer and adds an explicit acknowledgement. ack(26) is a content type in its own right, and an ACK record lists the RecordNumber values the sender of the ACK actually received. With that, a peer can retransmit only the missing records of a flight instead of all of it — which matters most where it hurts most, a long certificate flight split into many fragments on a constrained link.

Two design details are worth naming because interviewers use them:

ACKs are deliberately not part of the handshake transcript. They can be sent freely, lost freely and duplicated freely without changing the Finished computation, which is what lets them be a pure transport signal.
The timer does not go away. An ACK can itself be lost, so the timer remains the backstop; the ACK only makes the retransmission smaller and usually sooner.

Operating this on a real link

The exponential backoff has consequences that show up as product bugs rather than protocol bugs:

An application connect timeout shorter than the backoff kills handshakes that would have succeeded. If the client gives up at 5 seconds, it has allowed exactly two retransmissions on a link whose round trip may exceed that on its own.
A duty-cycled sender must stay awake for the schedule. A buoy that transmits and sleeps has to keep its radio up long enough to catch the reply and to honour its own retransmissions, or it will retry the handshake from scratch forever, paying the full cost each time.
Retransmission storms are self-limiting by design. The doubling is what stops a fleet of devices that all lost the same flight from synchronising into a loop at a fixed interval.
A very long handshake is a signal, not a stall. Repeated identical flights with growing gaps between them mean one direction is losing datagrams; if only the largest flight fails, suspect the path's size limit rather than the link's health.

The summary an interviewer is listening for: DTLS retransmits flights on an exponentially backed-off timer because nothing beneath it will, the retention of the last flight is part of the contract, and DTLS 1.3's ACK makes the repair surgical without removing the timer.

## Nobody underneath is going to do it Over a stream, a lost handshake message is repaired below TLS and the handshake layer never learns of it. Over datagrams there is no such layer, so DTLS has to detect loss and repair it itself — but only for the handshake. Once the handshake completes, the reliability machinery stops and application records take their chances. ## Flights, not messages DTLS groups the handshake into **flights**: the contiguous run of messages one side sends before it must wait for the other. A client's opening flight is its `ClientHello`; a server's reply flight in a full handshake carries its hello and its certificate messages through to the end of its turn. The unit of retransmission is the flight, not the message, and in DTLS 1.2 that is forced rather than lazy: a sender that gets no reply knows only that *something* in the exchange went missing. It cannot tell whether its own flight was lost, whether one fragment of it was lost, or whether the peer's answer was lost on the way back — so it resends everything it last sent. ## The timer RFC 6347 specifies the schedule as a recommendation, not a mandate, and the exact strength matters: - implementations **SHOULD** use an initial timer value of **1 second**, which is the minimum defined by RFC 6298; - the value **doubles at each retransmission**, up to the RFC 6298 **maximum of 60 seconds**; - the timer is **reset to the initial value** when the exchange makes progress and the sender moves to the next flight. So the gaps run 1, 2, 4, 8, 16, 32, 60, 60 … and a handshake on a bad link can be minutes old before it either completes or is abandoned. Two events restart a flight, not one: 1. **The timer expires** — retransmit the flight. 2. **A retransmitted message arrives from the peer** — the peer is asking again, which means its view is that your flight never landed, so retransmit rather than wait out your own timer. That second rule is why a peer must **retain its last flight** after sending it, including after the handshake appears finished: the final `Finished` flight may need to be sent again for a peer whose copy was lost. ## What DTLS 1.3 changes DTLS 1.3 keeps the timer and adds an explicit acknowledgement. `ack(26)` is a content type in its own right, and an ACK record lists the `RecordNumber` values the sender of the ACK actually received. With that, a peer can retransmit **only the missing records** of a flight instead of all of it — which matters most where it hurts most, a long certificate flight split into many fragments on a constrained link. Two design details are worth naming because interviewers use them: - **ACKs are deliberately not part of the handshake transcript.** They can be sent freely, lost freely and duplicated freely without changing the `Finished` computation, which is what lets them be a pure transport signal. - **The timer does not go away.** An ACK can itself be lost, so the timer remains the backstop; the ACK only makes the retransmission smaller and usually sooner. ## Operating this on a real link The exponential backoff has consequences that show up as product bugs rather than protocol bugs: - **An application connect timeout shorter than the backoff kills handshakes that would have succeeded.** If the client gives up at 5 seconds, it has allowed exactly two retransmissions on a link whose round trip may exceed that on its own. - **A duty-cycled sender must stay awake for the schedule.** A buoy that transmits and sleeps has to keep its radio up long enough to catch the reply and to honour its own retransmissions, or it will retry the handshake from scratch forever, paying the full cost each time. - **Retransmission storms are self-limiting by design.** The doubling is what stops a fleet of devices that all lost the same flight from synchronising into a loop at a fixed interval. - **A very long handshake is a signal, not a stall.** Repeated identical flights with growing gaps between them mean one direction is losing datagrams; if only the largest flight fails, suspect the path's size limit rather than the link's health. The summary an interviewer is listening for: **DTLS retransmits flights on an exponentially backed-off timer because nothing beneath it will, the retention of the last flight is part of the contract, and DTLS 1.3's ACK makes the repair surgical without removing the timer.**

Why must a peer keep its last flight after it believes the handshake is complete?
Because the other side may not agree. If the final flight was lost, the peer retransmits its own last flight and expects an answer; a sender that has already discarded its copy cannot produce one, and the handshake dies at the last step. Retaining the flight for a short period after completion is part of the contract.
Does the DTLS 1.3 ACK message replace the retransmission timer?
No. An ACK is itself an unreliable datagram and can be lost, so the timer stays as the backstop. What the ACK changes is the size of the repair: the sender learns which record numbers arrived and resends only the rest, instead of putting a whole multi-fragment flight back on a link that is already losing packets.
Why are ACKs kept out of the handshake transcript?
Because the transcript must be identical on both sides for the Finished computation to match, and a transport signal that may be sent, lost or duplicated at either peer's discretion cannot meet that bar. Excluding ACKs lets them be emitted whenever the receiver finds it useful without any cryptographic consequence.

saying these in an interview costs you the question

Says the transport beneath DTLS retransmits the lost flight
Claims DTLS retransmits single messages rather than whole flights
States a fixed retransmission interval with no backoff
Thinks DTLS 1.3 ACKs remove the need for the timer
Discards the final flight as soon as the handshake looks done
Assumes retransmission continues to protect application records

A buoy's DTLS handshake flight is lost on a satellite uplink; what resends it, and how does the timer behave?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Nobody underneath is going to do it

Flights, not messages

The timer

What DTLS 1.3 changes

Operating this on a real link

▾common follow-ups3 questions

▾red flags6 flags

Nobody underneath is going to do it

Flights, not messages

The timer

What DTLS 1.3 changes

Operating this on a real link

answer

go deeper