A network uses strict priority queuing with voice traffic in the high-priority queue. During heavy congestion, file-download traffic experiences complete starvation — no packets are delivered for minutes at a time. What alternative scheduling mechanism addresses this problem?
ADeep packet inspection, which reclassifies download traffic as high priority during starvation
BWeighted fair queuing, which guarantees a minimum bandwidth share to every traffic class
CRSVP signaling, which reserves bandwidth per-flow before transmission begins
DDSCP remarking, which upgrades lower-priority packets when they have been waiting too long
Strict priority queuing always serves the highest-priority queue first, which can completely starve lower-priority traffic when the high-priority queue never empties. Weighted fair queuing (WFQ) allocates bandwidth proportionally — each class gets a guaranteed minimum share even during congestion, preventing starvation while still favoring high-priority traffic. RSVP (option C) is a signaling protocol for IntServ reservation, not a scheduling solution for starvation. DSCP remarking (option D) doesn't exist as described.
Question 2 Multiple Choice
A service provider needs to offer guaranteed per-flow latency and bandwidth to 50,000 active video-conference sessions across a national backbone. Which QoS architecture is most appropriate?
ADiffServ, because it provides stronger per-flow guarantees and scales to large networks
BIntServ with RSVP, because it provides hard per-flow reservations — though scalability will be a concern
CBest-effort forwarding with large buffers, because modern links are fast enough to absorb bursts
DDiffServ, because per-hop behavior eliminates the need for any per-flow state across routers
IntServ with RSVP provides hard per-flow resource reservations — exactly what's needed for per-flow guarantees. The catch is that every router in the path must maintain state for every active flow, which scales poorly: 50,000 flows × hundreds of routers creates enormous state tables. DiffServ (option A, D) aggregates flows into classes and does NOT provide per-flow guarantees — its guarantees are statistical. This is the core scalability tradeoff between the two architectures.
Question 3 True / False
In a QoS system using weighted fair queuing, each traffic class is guaranteed a minimum share of bandwidth even when the total offered load exceeds link capacity.
TTrue
FFalse
Answer: True
This is the defining property of weighted fair queuing compared to strict priority queuing. WFQ distributes bandwidth according to configured weights — voice might get 40%, video 35%, best-effort 25% — and each class is served in proportion to its weight even during congestion. This prevents any class from being completely starved, which strict priority queuing does not guarantee.
Question 4 True / False
DiffServ provides stronger per-flow guarantees than IntServ, which is why it is the preferred architecture for large backbone networks.
TTrue
FFalse
Answer: False
This reverses the tradeoff. IntServ provides stronger per-flow guarantees via RSVP — resources are explicitly reserved for each flow end-to-end. DiffServ only marks packets into broad classes and applies per-hop behaviors; its guarantees are statistical and class-level, not per-flow. DiffServ is preferred in large backbone networks precisely because it scales well (no per-flow state), not because it provides better guarantees. The strength of guarantees and scalability trade off against each other.
Question 5 Short Answer
Why is traffic classification the necessary first step in any QoS system, and what information can be used to classify packets?
Think about your answer, then reveal below.
Model answer: Classification is necessary because QoS can only prioritize traffic if it knows which traffic belongs to which class. Without classification, all packets are indistinguishable and receive the same treatment — the default first-in-first-out behavior that QoS is designed to replace. Classification can use: port numbers (e.g., RTP ports for voice), DSCP bits in the IP header (6-bit field for marking traffic class), protocol type, or deep packet inspection examining payload content. Once classified, packets enter different queues that receive different scheduling treatment.
The scheduling and shaping mechanisms that follow — WFQ, policing, shaping — only work if packets have been sorted into classes. DSCP marking is particularly important because it allows classification to happen once at the network edge (by a trusted device close to the source) and persist hop-by-hop across the backbone without requiring each router to re-inspect every packet.