Queuing needs to know which packets matter. Marking is how a packet says so: three bits at layer 2, six bits at layer 3. The entire discipline is deciding who is allowed to set those bits, and where the network stops believing them.
Two labels
| Label | Where | Bits | Values |
|---|---|---|---|
| CoS (802.1p) | Ethernet tag | 3 | 0–7 |
| DSCP | IP header (ToS) | 6 | 0–63 |
CoS only exists on tagged frames, so it disappears at a routed boundary. DSCP survives end to end. In a routed district, DSCP is the label that matters, and CoS is a local hint on trunks.
The classes worth using
| Traffic | DSCP | Decimal | Per-hop behavior |
|---|---|---|---|
| Voice RTP | EF | 46 | Expedited forwarding, strict priority |
| Video conferencing | AF41 | 34 | Assured forwarding, low drop |
| Call signaling | CS3 | 24 | Below voice, above data |
| Transactional | AF21 | 18 | Business apps |
| Bulk | CS1 | 8 | Scavenger, first to drop |
| Best effort | 0 | 0 | Everything else |
Six classes is plenty. Twenty classes is a design that nobody can explain at 02:00.
The trust boundary
The rule: mark as close to the source as possible, and trust nothing you did not mark.
| Device | Action |
|---|---|
| IP phone | Marks voice EF, signaling CS3 (trusted) |
| Access point | Marks voice and video for WMM |
| Switch port | Trusts DSCP from phones/APs, re-marks from PCs |
| Edge router | Re-marks anything unexpected to 0 |
| ISP | Unknown — test it |
A workstation that can set EF on its own packets can starve voice. That is not a theoretical attack; it is what happens when a user installs a "gaming optimizer."
Classify at ingress, or not at all
If you trust DSCP from arbitrary endpoints, your QoS policy is a suggestion that any application can override. Re-mark at the access port and treat client markings as untrusted by default.
CoS and DSCP must agree
On a trunk, the frame has both labels. If the switch maps CoS 5 to DSCP 46 on one link and leaves it at 0 on another, voice is prioritized in one direction and not the other. Check the mapping table, not just the marking.
Worked example: a classroom port
One port serves a phone and a teacher laptop through the phone's PC port.
- Phone marks its own RTP as EF and signaling as CS3.
- The laptop's traffic arrives untagged or marked by the OS (usually 0, sometimes 46 if someone tried).
- The switch port trusts DSCP from the phone's MAC, and re-marks everything else to 0.
- The uplink carries voice at EF, data at 0.
- The edge shaper queues EF first.
Without step 3, a laptop can claim EF and win. With it, the laptop's claim is erased at the first hop.
What breaks in production
- Trusting all DSCP, so any device can claim priority.
- Re-marking at the edge only, so congestion inside the campus still treats voice like data.
- CoS/DSCP mismatch, producing asymmetric priority.
- Marking but no queuing, so the label has no effect.
- Too many classes, each with a policy nobody maintains.
- Assuming the ISP preserves markings without testing.
Checklist
- DSCP is the end-to-end label; CoS is local.
- Marking happens at the access edge, per device type.
- Client markings are not trusted.
- Six classes at most, each with a documented purpose.
- The CoS-to-DSCP mapping is consistent on every trunk.
- ISP treatment of DSCP has been measured.
Next
Labels are set. Continue with Queuing and Shaping, where they take effect.