skip to content

QoS and Traffic Shaping

3 roadmaps6 questions

Classify and mark at the trust boundary, queue with LLQ and CBWFQ at congestion points, and police or shape at rate changes. Interviewers use voice-quality scenarios to test the per-hop design.

on this pageshow

explore

questions

6

In DiffServ QoS, how should voice, video and bulk traffic be marked, and where should the network's trust boundary sit?

level: middleimportance: must knowfreq 42%

answer

  1. classify once, at the edge
  2. service classes in RFC 4594
  3. EF, AF4x, AF1x, DF
  4. drop precedence inside a class
  5. whose marking do you believe

basics

~20 s

Mark by service class at the edge: voice EF (46), interactive video AF41, signalling CS5, bulk AF11 or Lower Effort, everything else DF. Place the trust boundary as close to the source as possible, re-marking untrusted hosts and policing what you trust.

solid answer

~40 s

Mark at the network's edge using RFC 4594's service classes: voice bearer `EF` (46, RFC 3246) for low delay and jitter; interactive video `AF41` (34), with AF42 and AF43 as higher drop precedences (RFC 2597); call signalling `CS5`; routing `CS6`; backups `AF11` or Lower Effort `LE` (RFC 8622); anything unclassified `DF` (0). Classify once with multi-field rules (addresses, ports, interface), write the DSCP, and let interior routers classify on the DSCP alone. Put the **trust boundary** as close to the source as possible, normally the access port: re-mark untrusted PCs to `DF` unless a rule identifies their traffic, accept markings only from managed phones and servers, and police even those so a mis-marked application cannot flood the priority queue. RFC 4594 says marking from untrusted end-user devices SHOULD be verified and policed at ingress.

go deeper

for a junior

Recall the anchor codepoints: EF 46 for voice, AF41 for video calls, CS6 for routing, DF 0 for best effort, and that marking happens at the edge.

for a middle

Explain BA versus MF classification, the AF classes and their drop precedences, and why the trust boundary sits at the access port rather than in the core.

for a senior

Show how you would handle phones, PCs and servers on access ports, police trusted EF, and map CoS to DSCP across routed and switched hops.

for a principal

Weigh how many classes an organisation can actually operate, how far to trust endpoints, and how to keep markings consistent across provider and site boundaries.

## Classification and marking **Classification** sorts packets into traffic classes; **marking** writes the class into the packet so later devices need not repeat the work. RFC 2475 defines two kinds of classifier: - A **behaviour aggregate (BA) classifier** looks only at the DiffServ codepoint (DSCP). - A **multi-field (MF) classifier** looks at a combination of header fields: source and destination address, protocol, ports, and information such as the incoming interface. The design pattern is to do the expensive MF classification once, at the edge, write a DSCP, and let every interior router use cheap BA classification. The DSCP lives in the IP header's former Type of Service byte; the field's layout is a header topic, so here only the codepoint values and what they buy matter. ## Which codepoint for which traffic RFC 4594 (Informational) gives configuration guidelines for DiffServ service classes. The rows most designs use: | Traffic | RFC 4594 service class | Codepoint | Decimal | Behaviour defined in | |---|---|---|---|---| | Routing protocols | Network Control | CS6 | 48 | RFC 2474 | | Voice bearer | Telephony | EF | 46 | RFC 3246 | | Call signalling | Signaling | CS5 | 40 | RFC 2474 | | Interactive video calls | Multimedia Conferencing | AF41, AF42, AF43 | 34, 36, 38 | RFC 2597 | | Streaming video | Multimedia Streaming | AF31, AF32, AF33 | 26, 28, 30 | RFC 2597 | | Interactive business apps | Low-Latency Data | AF21, AF22, AF23 | 18, 20, 22 | RFC 2597 | | Backups, file transfer | High-Throughput Data | AF11, AF12, AF13 | 10, 12, 14 | RFC 2597 | | Unclassified | Standard | DF (CS0) | 0 | RFC 2474 | | Scavenger traffic | Low-Priority Data | LE | 1 | RFC 8622 | The families behind those codepoints: - **Expedited Forwarding (EF)**, codepoint 101110 (46), RFC 3246. A node must serve EF at or above a configured rate regardless of other traffic, so EF packets usually meet short or empty queues: low delay, low jitter, low loss. - **Assured Forwarding (AF)**, RFC 2597. Four classes, each allocated its own forwarding resources (buffer and bandwidth), and three **drop precedences** inside each. When an AF class congests, AFx3 is dropped before AFx2, and AFx2 before AFx1. A node must not reorder packets of one microflow within a class regardless of drop precedence, so in-profile and excess packets of a flow share one queue. - **Class Selectors** (CS0 to CS7, codepoints of the form xxx000), RFC 2474. They keep compatibility with the older IP Precedence values. - **Default (DF)**, 000000. RFC 2474 says a packet with an unrecognised codepoint SHOULD be forwarded as if marked Default. - **Lower Effort (LE)**, 000001, RFC 8622. It replaced RFC 4594's use of CS1 for low-priority data, because networks treating CS1 as RFC 2474 defines it could give it priority over best effort. ## The trust boundary A marking is only as good as whoever set it. The **trust boundary**, an industry term rather than an RFC one, is the point where the network starts believing DSCP values instead of overwriting them. RFC 4594 states the rule for the Telephony class: marking from untrusted sources (end-user devices) SHOULD be verified at ingress using MF classification, and such flows SHOULD be policed at ingress; policing is optional for trusted sources whose behaviour is ensured by other means. RFC 3246 adds that ingress conditioning MUST ensure only packets entitled to EF are marked EF inside the domain. Where to place it: 1. **As close to the source as possible**: the access switch port, or the first router at a site without managed switches. Every hop beyond it can use BA classification. 2. **Untrusted ports** (user PCs, guest devices): re-mark to DF, or to what an MF rule identifies. Otherwise a host that marks everything EF lands in the priority queue. 3. **Conditionally trusted devices** (phones and video endpoints the IT team manages): accept their EF or AF41 marking once the device is identified, and only up to a policed rate. 4. **Trusted servers and network devices**: accept the marking, still policing at the edge of the DiffServ domain. 5. **Between domains** (a provider handoff): condition and re-mark according to the agreement; RFC 2475 places such conditioning in boundary nodes. ## Layer 2 priority versus DSCP On an 802.1Q trunk the VLAN tag carries a 3-bit priority value, often called **CoS** (an IEEE field described with the tag). It exists only on that Ethernet hop: a router forwarding the packet builds a new frame and does not carry the old tag's priority across. The DSCP rides in the IP header end to end. So a design maps CoS to DSCP at the first routed hop when a device marks only CoS, and maps DSCP back to CoS where a switch queues by CoS.

  • An IP phone has a PC plugged into it; how can one access port trust the phone's marking but not the PC's?
    The phone and PC usually sit in different VLANs on the same port: the phone's voice VLAN and the PC's data VLAN. Policy can trust markings arriving in the voice VLAN, ideally only after the device is identified, and re-mark the data VLAN's traffic to DF or to what a multi-field rule identifies. Police EF on the voice side so a compromised or misconfigured device cannot exceed the engineered voice rate.
  • Why do AF classes carry three drop precedences instead of one codepoint each?
    Drop precedence lets one class carry in-profile and excess traffic without reordering a flow. A policer marks traffic within the contracted rate AFx1 and the excess AFx2 or AFx3; under congestion the node drops the higher precedence first. RFC 2597 requires each class to accept all three and yield at least two loss levels, with AFx1 never more likely to be dropped than AFx2 or AFx3.

saying these in an interview costs you the question

  • Hosts can be trusted to set their own DSCP correctly by default.
  • AF41 is the standard codepoint for voice bearer traffic.
  • A higher AF class number always means higher priority than lower AF classes.
  • The 802.1Q priority bits stay with a packet across routed hops.
  • Every router should re-classify every packet with multi-field rules.
  • Drop precedence decides which AF class the scheduler serves first.
open as a page

In QoS design, how do traffic policing and traffic shaping differ, and where does each belong when a branch's 1 Gb/s port connects to a 100 Mb/s WAN contract?

level: seniorimportance: must knowfreq 36%

basics

~20 s

Policing drops or re-marks traffic above a rate at once, adding no delay; shaping buffers the excess and sends it later, adding delay instead of loss. The branch shapes egress to 100 Mb/s with queues inside; the provider polices.

open as a page

In IP networks, what problem does quality of service (QoS) solve, and why does it change nothing on a link that is never congested?

level: juniorimportance: should knowfreq 46%

basics

~20 s

QoS decides which packets wait and which are dropped when traffic reaches an output faster than the link can send it. It trades delay, jitter and loss between classes but adds no bandwidth, so without a queue it has nothing to decide.

open as a page

In router QoS queuing, why pair a strict-priority queue for voice with class-based weighted fair queues, and why must the priority queue be policed?

level: middleimportance: should knowfreq 30%

basics

~20 s

A strict-priority queue sends waiting voice first, giving the low delay and jitter Expedited Forwarding needs; weighted class queues guarantee every other class a minimum share. The priority queue must be rate-limited, or excess priority traffic starves every other class.

open as a page

On a congested router queue carrying many TCP flows, why does tail drop cause global synchronisation, and how do RED and weighted RED avoid it?

level: seniorimportance: should knowfreq 19%

basics

~20 s

Tail drop discards only when a queue is full, so many flows lose packets at once, slow down together and leave the link idle. RED drops randomly and early as the average queue grows; weighted RED sets thresholds per drop precedence.

open as a page

For QoS on a branch's 20 Mb/s WAN link carrying voice, video calls and backups, where calls break up at busy hours, what end-to-end design would you build?

level: principalimportance: should knowfreq 14%

basics

~20 s

Find the congestion points, mark at the trust boundary, shape to the contracted rate, give voice a policed priority queue sized from calls times per-call rate, give other classes minimum shares, and cap calls with admission control so the policer never drops.

open as a page