A headquarters edge carries voice, video conferencing, and bulk backup sharing a congested 200 Mbps link with TCP starvation during backups. Which queuing and congestion avoidance design protects real-time traffic while keeping TCP efficient?

The correct design is right because LLQ provides strict low-latency priority with policing for voice to control delay and jitter, while CBWFQ guarantees minimum bandwidth for video conferencing and bulk backup so TCP does not starve during congestion on the 200 Mbps edge, and WRED provides early random drops based on DSCP and queue depth to signal TCP senders to back off gradually and avoid tail-drop bursts and global synchronization, preserving both real-time quality and bulk throughput. A design using only CBWFQ with WRED and no strict priority fails by scheduling concept because without LLQ voice still queues behind video and backup bursts, adding delay and jitter that violates real-time requirements even though TCP remains efficient. A design using LLQ with CBWFQ but tail drop instead of WRED fails by congestion-avoidance concept because full queues then drop many TCP packets at once, triggering synchronized retransmits and sawtooth throughput that recreates starvation during backups despite protecting voice. A design applying LLQ for voice while leaving video and backup as best effort fails by classification concept because video also needs guaranteed bandwidth and low jitter and cannot be lumped with bulk backup, so conference quality degrades and backup contention remains unmanaged without CBWFQ and WRED. As an exam caveat, remember LLQ is strict priority plus a policer to prevent starvation of other queues, not unlimited priority, and WRED helps only TCP-based classes, not UDP voice. As a practical check, verify DSCP markings end to end, confirm priority and bandwidth reservations match the 200 Mbps policy, and monitor policy-map interface counters for WRED early versus tail drops during a backup window.