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

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

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
    Paste the supplied diagram and sketch into Wokwi and inspect the Burst load and Urgent alert inputs plus both status LEDs.
    You will see
    GPIO12 controls burst load, GPIO13 injects an alert, green shows protected delivery, and yellow shows a background drop.
    Why it matters
    The hardware boundary makes traffic events and receiver evidence visible.

  2. Step 2

    Do
    Inspect the BACKGROUND_CAPACITY constant and the strict-priority alert handler before running.
    You will see
    The background queue is bounded at 4 while an alert is dequeued before background work.
    Why it matters
    A queue policy must name both who is protected and what yields under contention.

  3. Step 3

    Do
    Start the simulation and open Serial Monitor at 115200 baud.
    You will see
    QOS POLICY ESP32 READY appears with protected=ALERT, lower=BACKGROUND, drop=TAIL_DROP, and capacity=4.
    Why it matters
    A declared policy turns later queue and drop rows into auditable evidence.

  4. Step 4

    Do
    Press Burst load once and wait for the queue to fill.
    You will see
    BURST=ON reports three offered background items per tick and QUEUE reaches background=3/4.
    Why it matters
    The burst makes contention reproducible instead of inferring it from a quiet run.

  5. Step 5

    Do
    Keep burst mode on for another sampling tick.
    You will see
    DROP class=BACKGROUND appears with reason=TAIL_DROP while the queue remains bounded.
    Why it matters
    QoS moves delay or loss; this record names the intended sacrifice instead of hiding it.

  6. Step 6

    Do
    Press Urgent alert while burst mode is still on.
    You will see
    DEQUEUE class=ALERT appears before BACKGROUND and the green LED flashes.
    Why it matters
    The selected mechanism is only credible when the protected class wins during contention.

  7. Step 7

    Do
    Inspect the receiver-style delivery row for the same alert sequence.
    You will see
    DELIVER class=ALERT reports delay_ms=5 and stale=NO.
    Why it matters
    Sender configuration is not enough; the receiver outcome must still be inside the useful window.

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