Protect urgent traffic with a bounded queue policy

Observe strict-priority service and bounded background tail-drop during a controlled traffic burst.

Cloud Clara: I want you to name the protected traffic, the intended sacrifice, and the receiver evidence that proves the policy., your practice guide

Cloud Clara: I want you to name the protected traffic, the intended sacrifice, and the receiver evidence that proves the policy.
Predict the reading, then compare it with the measurement.

Wokwi ESP32

Third party Tool

Tier 1 · Web · No account

Version tested: Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-10. Date: 2026-09-10.

Open the ESP32 editor, paste diagram.json, then paste sketch.ino.

Open Wokwi to paste in the files (new tab)

Get the files

Use both prepared files. This is a paste-in setup; saving a project requires a Wokwi account.

diagram.json

1,460 bytes · Circuit connections

Download

sketch.ino

2,014 bytes · ESP32 program

Download

  1. Use the launch button above to open the ESP32 editor in Wokwi.
  2. Select the editor’s diagram.json tab and replace all its text with the supplied diagram.json.
  3. Select the sketch.ino tab, replace all its text with the supplied sketch.ino, then click Start Simulation.

Steps

Screens captured against Wokwi ESP32 Compiled and booted by the Wokwi gate (ESP32 Arduino core 3.3.11); captured in the Wokwi web editor on 2026-09-10 on 2026-09-10; the tool may have moved on — the text steps are the contract.

  1. Step 1

    Do
    In Wokwi's project editor, paste the supplied diagram and sketch into Wokwi and inspect the Burst load and Urgent alert inputs plus both status LEDs.
    You will see
    Burst button connects ESP32 GPIO12 to ground when pressed (diagram.json line 14). Alert button connects ESP32 GPIO13 to ground when pressed (diagram.json line 15). Delivered LED anode connects to ESP32 GPIO2 and returns through r1 to ground (diagram.json line 16). Dropped LED anode connects to ESP32 GPIO4 and returns through r2 to ground (diagram.json line 17). Both LED series resistors are 220 Ω (diagram.json lines 8, 10).
    Why it matters
    The two grounded buttons inject background load and urgent alerts separately. The protected-delivery and dropped-status LED paths show which later scheduling outcome occurred.

  2. Step 2

    Do
    In Wokwi's sketch editor, inspect the BACKGROUND_CAPACITY constant and the strict-priority alert handler before running.
    You will see
    An alert press is handled in its own branch before dequeue and delivery are logged (sketch.ino lines 28–32). Detect an alert-button press: if (priorAlert == HIGH && alertNow == LOW) { (sketch.ino line 28). Increment the message sequence: sequenceId++; (sketch.ino line 29). Turn on the delivered LED: digitalWrite(DELIVERED_LED, HIGH); (sketch.ino line 30). Print alert dequeue order: Serial.printf("DEQUEUE class=ALERT seq=%d before=BACKGROUND depth=%d\n", sequenceId, backgroundDepth); (sketch.ino line 31). Print alert delivery evidence: Serial.printf("DELIVER class=ALERT seq=%d delay_ms=5 stale=NO\n", sequenceId); (sketch.ino line 32).
    Why it matters
    The background capacity bounds queued load. The alert branch records and lights protected delivery before background work, which is the ordering tested by the later burst and alert inputs.

  3. Step 3

    Do
    In the Simulation toolbar, start the run and read the Serial Monitor heading.
    You will see
    Input: supplied QoS policy sketch. Observed: "QOS POLICY ESP32 READY". Observed: "POLICY protected=ALERT lower=BACKGROUND drop=TAIL_DROP capacity=4". Expected: both class priority and queue capacity are declared.
    Why it matters
    The protected class is ALERT. BACKGROUND is the lower priority class. TAIL_DROP is the named overflow rule. The background capacity is four items.

  4. Step 4

    Do
    In the Simulation panel, hold Burst load once and read Serial Monitor.
    You will see
    Input: press Burst load once. Observed: "BURST=ON offered_background=3_per_tick". Observed: "QUEUE alert=0 background=3/4 burst=ON policy=STRICT_PRIORITY". Expected: burst mode offers background work and fills the queue.
    Why it matters
    The offered load is three items per tick. The bounded queue reaches three of four slots. The alert queue is still empty. This establishes the overload condition before an urgent alert.

  5. Step 5

    Do
    In the Serial Monitor panel, keep Burst load on until the background queue drops a seventh item.
    You will see
    Input: leave Burst load ON for another sampling tick. Observed: "DROP class=BACKGROUND count=2 reason=TAIL_DROP total=3". Observed later: "DROP class=BACKGROUND count=2 reason=TAIL_DROP total=5". Observed later: "DROP class=BACKGROUND count=2 reason=TAIL_DROP total=7".
    Why it matters
    The queue remains bounded at three of four occupied slots. Each tick can reject excess background work. The cumulative drop total rises from three to seven. The real capture shows this same sequence before an urgent alert.

  6. Step 6

    Do
    In the Simulation panel, hold Urgent alert while Burst load remains on; read Serial Monitor.
    You will see
    Input: press Urgent alert with burst still on. Observed: "DEQUEUE class=ALERT seq=1 before=BACKGROUND depth=3". Observed: background depth was three at the dequeue. Expected: the urgent item is served before queued background work.
    Why it matters
    The alert leaves the queue before BACKGROUND. The depth field shows background work was waiting. The serial row demonstrates strict priority in this run. The LED is a visual cue; this row is the ordering evidence.

  7. Step 7

    Do
    In the Serial Monitor panel, read the delivery row for the urgent alert.
    You will see
    Input: inspect the delivery after Urgent alert. Observed: "DELIVER class=ALERT seq=1 delay_ms=5 stale=NO". Observed: the sequence number remains 1. Expected: protected delivery is short and not stale.
    Why it matters
    The delivery row follows the dequeue event. The delay is reported as 5 ms by this model. The stale flag is NO. This is simulated policy evidence, not a network latency measurement.

Chapter checks

These questions refer to the chapter’s examples. Use the return links to review their answers.

  1. A remote pump station shares one cellular gateway for leak alarms, pump commands, tank-level telemetry, diagnostics, and firmware downloads. During a backhaul outage the local controller acted, but the cloud dashboard only showed the burst after reconnect. What should the real-world QoS decision record compare first?

    Return to the chapter’s knowledge check

  2. A remote monitoring gateway reconnects after an outage and begins sending old logs, current status changes, and queued control acknowledgements at the same time. What is the strongest QoS response?

    Return to the chapter’s knowledge check

  3. A field gateway reconnects and the broker acknowledges a queued valve command, but the command's expiry window has already passed. What should the real-world QoS policy do?

    Return to the chapter’s knowledge check

Return to QoS in Real-World Systems · Browse Labs