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?
answer
- find both congestion points
- a delay budget, not a feeling
- calls times per-call rate
- the extra call hurts every call
- trade bandwidth against control
basics
~20 sFind 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.
solid answer
~50 sFirst find the congestion points: the branch router's egress into the 20 Mb/s circuit, which you control, and the provider's egress toward the branch, which you do not unless its service honours your classes. Shape to the contracted rate if the port is faster, and nest the queuing policy inside the shaper. Mark at the trust boundary following RFC 4594: voice `EF`, video calls `AF41`, signalling `CS5`, backups `AF11` or `LE`, the rest `DF`. Give voice a policed strict-priority queue sized from calls multiplied by per-call rate (about 80 kb/s per call for a 64 kb/s codec in 20 ms packets), give the other classes minimum shares with weighted RED on bulk, and pair the priority policer with **call admission control**; otherwise one extra call makes the policer drop packets from every call. Verify at the receivers against ITU-T G.114's roughly 150 ms one-way delay guidance, plus measured jitter and loss.
go deeper
Recall the pieces: mark voice EF, give it a priority queue with a limit, and keep backups in a lower class.
Explain how per-call bandwidth is computed from codec rate, packet interval and header bytes, and how a link's classes are given shares that sum to the line rate.
Show that you locate both congestion points, shape to the contract, size the priority limit, and use admission control so the policer never drops.
Own the trade-off between buying bandwidth, provider class-of-service contracts and engineering QoS, and set how much of a link may ever be pre-emptible.
## Start with the budget Voice quality is a budget, not a feeling: - **One-way delay**: ITU-T Recommendation G.114 (an ITU-T text, not an RFC) gives roughly 150 ms one-way as the level below which most voice users are satisfied. Packetisation, propagation, serialisation, queuing and the receiver's de-jitter buffer all spend it. - **Jitter**: the receiver's de-jitter buffer absorbs delay variation, but every millisecond of buffer is a millisecond of delay. RFC 3246 defines jitter as the variation between maximum and minimum delay, and queues are where it comes from. - **Loss**: voice is not retransmitted; codecs conceal occasional isolated losses, while bursts are audible. Numeric jitter and loss targets in design guides are rules of thumb, not standards. RFC 4594 rates the Telephony class as having very low tolerance to loss, delay and jitter. ## Find the congestion points 1. **Branch egress (upload)**: a 1 Gb/s LAN into a 20 Mb/s circuit. Your router controls this queue, provided it sees the congestion; if the port is faster than the contract, shape to the contract and nest the queues inside. 2. **Provider egress toward the branch (download)**: the provider's edge queues traffic coming down to you, and your router's policy cannot touch it. You need a provider service that honours your DSCP classes, or a shaper at the hub that sends toward the branch no faster than its circuit, so the queue forms where you control it. 3. **Across the provider**: markings may be re-marked at its boundary; confirm the codepoint mapping in the contract and check what arrives. ## Classify and mark at the trust boundary | Traffic | RFC 4594 class | Codepoint | Treatment | |---|---|---|---| | Voice bearer | Telephony | EF (46) | strict priority, policed | | Call signalling | Signaling | CS5 (40) | small guaranteed share | | Video calls | Multimedia Conferencing | AF41 (34) | guaranteed share | | Routing | Network Control | CS6 (48) | small guaranteed share | | Business apps | Low-Latency Data | AF21 (18) | guaranteed share | | Backups | High-Throughput Data, or Lower Effort | AF11 (10) or LE (1) | minimum share, early drop | | Everything else | Standard | DF (0) | remaining share | ## Size the priority queue Per-call rate for a 64 kb/s codec (ITU-T G.711) sending 20 ms packets: 1. Payload: 64,000 b/s multiplied by 0.02 s is 1,280 bits, or 160 bytes. 2. Headers: RTP's 12-byte fixed header (RFC 3550, outside this corpus), UDP's 8 bytes (RFC 768) and IPv4's 20 bytes (RFC 791) add 40 bytes. 3. Rate: 200 bytes at 50 packets per second is 10,000 bytes/s, or 80 kb/s before layer-2 overhead. Twenty concurrent calls need 1.6 Mb/s, 8 % of 20 Mb/s. Set the priority limit with headroom, say 2 Mb/s (10 %), which carries 25 calls. A widely quoted design rule of thumb keeps strict-priority traffic to about a third of a link so the other classes are not crowded out; it is a guideline, not a standard. A worked allocation for the 20 Mb/s link: EF 2 Mb/s (10 %, policed); AF41 6 Mb/s (30 %); CS5 0.4 Mb/s (2 %); CS6 0.4 Mb/s (2 %); AF21 4 Mb/s (20 %); AF11 2 Mb/s (10 %, minimum, weighted RED); DF 5.2 Mb/s (26 %). The total is 20 Mb/s and 100 %. ## Admission control: the call that breaks every call The priority queue's policer, which RFC 3246 requires, discards EF above its limit, but it cannot tell which call is the extra one. With room for 25 calls (ignoring layer-2 overhead), a 26th call makes the policer drop packets from all 26, so every call degrades together. **Call admission control**, the call server refusing calls beyond the engineered capacity, keeps the policer from ever firing. RFC 4594 makes the same pairing: admission control keeps telephony within its capacity, policing at ingress bounds the input rate, and a priority queue then gives nominal delay. RFC 5865 goes further and defines a separate codepoint, VOICE-ADMIT (101100, decimal 44), for traffic that has passed capacity admission. ## Serialisation and the slow-link trap At 20 Mb/s a 1,500-byte packet takes 12,000 bits divided by 20 Mb/s, or 0.6 ms, so a voice packet stuck behind one barely notices. At 1 Mb/s the same packet takes 12 ms, and on links that slow designs often fragment large packets so voice can be interleaved. On this branch, serialisation is not the problem; queuing is. ## The trade-offs a lead owns - **Bandwidth or engineering?** If the link is saturated for hours, QoS only chooses who suffers; the backups still need a window, a lower class or more capacity. - **How much priority?** A generous EF limit protects more calls but lets more traffic pre-empt everything else; a tight one makes admission control mandatory. - **How far to trust endpoints?** Trusting managed phones saves classification work; trusting PCs invites EF abuse. - **Provider classes**: a class-based WAN service costs more but fixes the download direction; without it, the inbound queue is the provider's to manage. Then verify: per-class drop counters, zero drops on the priority policer, and jitter and loss measured at the receivers.
- Calls break up only for audio coming into the branch; what does that tell you?The congestion point is the provider's egress toward the branch, not your router's upload queue. Your outbound policy cannot fix it. Either buy a class-based service that honours your DSCP on the downstream side, or shape at the hub so traffic toward the branch never exceeds the branch circuit, moving the queue to a device whose priority queue you control.
- Why not just put backups in Lower Effort and skip the other classes?Demoting backups protects everything above them, which may be enough on a small site. But video calls, business applications and routing traffic would then share one best-effort queue, so a large download still competes with video. RFC 8622's Lower Effort class is useful for traffic that should yield to everything; it does not replace minimum shares for the classes that need assurance.
saying these in an interview costs you the question
- Marking voice EF on the branch router also protects audio coming into the branch.
- The priority queue's policer can drop just the newest call when calls exceed capacity.
- The 150 ms one-way voice target is an IETF requirement in the DiffServ RFCs.
- Serialisation delay is the main voice problem on a 20 Mb/s link.
- Putting video calls in the voice priority queue is always the safer design.