Limit in-flight work
NSTART caps the number of outstanding interactions to one server. The RFC 7252 default is one, which is conservative and easy to implement.
CoAP Congestion Control Workbench
Animate RFC 7252 NSTART limiting, randomized ACK timeout, exponential backoff, retransmission risk, and an RTT-aware comparison.
animation
coap
protocols
congestion-control
reliability
interactive
Interactive CoAP congestion control workbench for learning RFC 7252 NSTART, ACK_TIMEOUT, ACK_RANDOM_FACTOR, MAX_RETRANSMIT, exponential backoff, retry storms, and RTT-aware congestion-control ideas.
CoAP Congestion Control Workbench
Watch a constrained CoAP client decide when it may send, when it must wait, and how retransmission timers expand after loss. Step through NSTART slots, randomized ACK timeout, exponential backoff, and the difference between safe recovery and a retry storm.
Mode
RFC 7252
Outstanding
0 / 1
Next timeout
2.7 s
Diagnosis
Healthy
Wait before retry
A Confirmable message starts a timer. If no ACK or response arrives, the client retransmits the same message rather than starting unlimited new work.
Double after loss
Each retry waits longer. This exponential backoff gives the network time to recover instead of adding more traffic during congestion.
Add jitter
ACK_RANDOM_FACTOR spreads retry times. Without it, many clients can wake up and retransmit together.
Live Congestion Scene
One client sends Confirmable requests and waits for each result before opening the next interaction.
Queue
Requests wait for a free NSTART slot.
Transmit
Client sends a CON message.
Wait
Timer runs before retry.
Complete
ACK/response frees the slot.
Client request
->
CON GET
Waiting for slot
<-
ACK / response
ACK
Slot released
CoAP server
Normal response path
NSTART slots
1 slot enabled
Retry timer ladder
Initial timeout then powers of two
Attempt
0 of 4Wait window
2.0-3.0 sElapsed
0.0 sTransmit wait
93.0 s max
Healthy lock-step behavior
With NSTART set to one, the client keeps only one interaction outstanding and queues later requests until the ACK or response arrives.
Event trace
CoAP congestion quick reference RFC parameters, formulas, and what to look for
| Control | Default | Meaning | Learning signal |
|---|---|---|---|
NSTART |
1 | Maximum simultaneous outstanding interactions to one server. | Higher values raise throughput pressure and can be unsafe without stronger congestion-control measurement. |
ACK_TIMEOUT |
2 s | Base timeout before retransmitting a Confirmable message. | Lower values can retry too soon on slow links; higher values slow recovery. |
ACK_RANDOM_FACTOR |
1.5 | Jitter multiplier for the initial timeout. | Values above 1.0 spread clients apart and reduce synchronized retries. |
MAX_RETRANSMIT |
4 | Maximum number of retransmission attempts. | More retries improve delivery chance but keep state and traffic alive longer. |
Timer formula
The workbench uses initial = ACK_TIMEOUT * random(1, ACK_RANDOM_FACTOR), then doubles that initial timeout for each retransmission step.
2-3 s default first wait
4-6 s next wait
8-12 s after that
Transmit span
MAX_TRANSMIT_SPAN covers the time from first send to the last retransmission. With defaults, it is about 45 seconds.
2+4+8+16
x 1.5
45 s
Transmit wait
MAX_TRANSMIT_WAIT includes the final wait before giving up. With defaults, it is about 93 seconds.
2+4+8+16+32
x 1.5
93 s
Learning support How to read the animation independently
Start with NSTART
Watch the slot strip before the packet lanes. If every enabled slot is busy, the next request must wait in the queue.
Then inspect the timer
The retry ladder shows why one missed ACK does not immediately become a flood. Each timeout gets longer.
Look for retry clustering
In the no-jitter scenario, several clients retry in nearly the same time window. That is the behavior randomization is meant to reduce.
Technical notes and sources Standards baseline and comparison limits
Standards baseline
The default values and derived timing formulas are taken from RFC 7252 Sections 4.7 and 4.8. The workbench treats NSTART as a per-server outstanding-interaction limit.
RTT-aware mode
The comparison mode is a teaching simplification inspired by CoCoA draft ideas. It shows why RTT measurement can help, but it is not a full implementation of the expired Internet-Draft.
Loss model
The loss scenarios are deterministic so learners can repeat them. They illustrate congestion-control consequences rather than simulating a specific radio or MAC layer.