Summary

  • RFC 5238 warns that DTLS must not retransmit a request that DCCP has queued but not actually transmitted. Where possible, the upper timer should begin when DCCP hands the message to IP, not when it merely accepts the work.
  • Layered reliability creates distinct receipts: queue admission, lower-layer handoff, packet transmission, peer receipt, DCCP handshake completion, DTLS progress and application readiness. Treating them as one event can manufacture congestion and false loss evidence.

A timeout without a transmitted packet

The upper handshake submits a record. The lower transport accepts it, but congestion control does not yet permit release. From DTLS's viewpoint, time passes without a response. If its retransmission timer began at submission, expiry appears to say that the network lost a request. In reality, the request may still be local.

The retry then joins the same queue. It consumes memory, competes for the same paced opportunity and can delay the original further. The system cites delay as evidence for duplication, while duplication contributes to delay.

RFC 5238 gives a precise remedy. An implementation should avoid retransmitting a request that DCCP has queued but not actually transmitted. If the DCCP interface exposes the event, DTLS can delay arming its timer until DCCP transfers the message to the IP layer.

Two handshakes do not become one

DCCP is connection-oriented and has a handshake before ordinary data. DTLS has another handshake before protected application traffic. The simple arrangement performs them in series: DCCP first, DTLS second.

RFC 5238 also permits partial overlap. DTLS handshake records can ride inside DCCP-Request and DCCP-Response. That saves potential round trips, but it does not merge their guarantees. The DCCP handshake is reliable; Application Data carried inside its handshake packets is not necessarily reliable. A server may discard that data, and a retransmitted DCCP handshake packet may omit the Application Data included the first time.

DTLS therefore retains its own retransmission logic. Yet a DTLS record sent inside DCCP-Request cannot be retried as ordinary DCCP data until the DCCP handshake completes. RFC 5238 requires the upper retransmission timer to wait before restarting, preventing several DTLS retries from accumulating before any can leave.

Similar clocks can amplify one another

Both handshake procedures use broadly similar timeout and backoff behavior. Their independence matters. One clock protects DCCP connection progress; the other protects DTLS handshake progress. A timeout at one layer does not prove the subject of the other failed.

Large DTLS handshake messages can be throttled by DCCP congestion control long enough to trigger DTLS timeout logic. Adding retries to that condition may worsen congestion and delay establishment. The lesson is not that retransmission is bad. Retransmission after evidence of non-response is a recovery tool. Retransmission before evidence of actual sending is speculative duplication.

The counter should answer a defined question: how long since the lower layer released this attempt? Starting it at queue admission silently changes the question to: how long since the application asked for service? Those intervals include different causes and authorize different remedies.

Sequence numbers keep their own subjects

Both protocols number their packets or records. RFC 5238 explicitly rejects a shortcut: there is no connection between a DCCP packet sequence number and the DTLS record sequence number it carries, nor between DCCP synchronization and DTLS anti-replay protection.

This is another warning against borrowing evidence across layers. A lower sequence can establish lower-layer ordering or synchronization within its rules. It cannot certify the upper security record's replay state. Shared transport does not create shared meaning.

The same discipline applies to size. A DTLS record must fit inside one DCCP data packet and must not exceed the DCCP maximum packet size currently in force. That maximum may vary with congestion state. A size accepted yesterday is not proof that the current path and control state can carry it now.

The handshake can shape the service that follows

The cost does not end when the security handshake completes. RFC 5238 notes that handshake traffic can leave DCCP's congestion controller in a state unsuited to the application stream. With CCID 2, a large handshake might trigger multiplicative decrease that the later application pattern would not have caused. The application then waits for additive increase to restore throughput. CCID 3 may be worth considering where smoother rate variation matters.

This is not evidence that one CCID always wins. It establishes a transition boundary. “Handshake complete” describes security establishment. It does not prove that congestion state is ready for the application's demand.

What the record does not establish

RFC 5238 names no current product, library, operating system, deployment, trace, outage or benchmark. The IANA DCCP registry establishes protocol namespaces, not use. Later DTLS specifications establish evolution of the security protocol, not adoption of DTLS over DCCP.

DCCP-to-IP handoff is also not physical transmission, peer receipt or session establishment. It is simply a stronger start event for an upper timer than local queue admission. A well-governed receipt chain preserves every boundary rather than promoting one into proof of the next.

Give each timer an owned event

For each attempt, record submission time, queue admission, congestion-controller disposition, DCCP-to-IP handoff, transport sequence identity, actual send observation if available, peer acknowledgement or response, DCCP handshake state, DTLS flight and application-release event.

Name the component that owns each timer and the precise event that arms it. Suppress upper retries while the lower layer still reports the original queued. Preserve cancellations, superseded attempts and late responses rather than counting them all as network loss.

Lu Heng's running-code priority matters here. An API accepting work is not the same reality as a packet leaving. The principal who configures the timer must be answerable for the evidence boundary, because the timer does more than observe delay: it can create new traffic.

Sources

Additional standards record

  1. RFC 5238 plain text
  2. RFC 5238 information record
  3. RFC 5238 Datatracker record
  4. RFC 5238 history
  5. RFC 5238 errata
  6. RFC 5238 referenced-by record