How Packet Scheduling Algorithms Works: Networking Explained

1. Introduction and Core Concepts

Packet scheduling algorithms are the fundamental decision-making mechanisms that determine the order and timing in which data packets are transmitted over a shared network link. Whenever multiple packet flows compete for the same finite resource — whether it is a router's outbound interface, a wireless access point, or a data center switch — a scheduler must decide which packet goes next. Without intelligent scheduling, networks would devolve into unpredictable, unfair systems where critical traffic like voice calls could be starved by bulk file transfers.

At its core, packet scheduling addresses three interrelated problems: contention, fairness, and quality of service (QoS). Contention occurs because link capacity is limited; if ten flows each want 100 Mbps on a 1 Gbps link, they can coexist, but if they each want 200 Mbps, someone must wait. Fairness defines how that waiting is distributed — should it be equal, proportional to payment, or based on application priority? QoS translates these abstract goals into concrete guarantees such as bounded latency, minimum throughput, and controlled jitter for sensitive applications.

Understanding packet scheduling algorithms is essential for anyone designing or operating modern networks. From Internet Service Providers (ISPs) enforcing Service Level Agreements (SLAs) to cloud providers isolating tenants in multi-tenant data centers, and from 5G base stations slicing radio resources to operating system kernels managing socket buffers, scheduling logic is ubiquitous. The choice of algorithm directly impacts user-perceived performance, network utilization, and even revenue, making it a critical topic in networking algorithms.

Key Terminology

Before diving deeper, it is important to define the core components of any scheduling system. A flow is a sequence of packets sharing common attributes, typically defined by the 5-tuple of source/destination IP, source/destination port, and protocol. A queue is a buffer where packets of one or more flows wait before transmission. The scheduler is the algorithm that selects the next queue to service, while the classifier assigns incoming packets to the appropriate queue. Finally, work-conserving schedulers never leave the link idle when there is a packet queued, whereas non-work-conserving schedulers may intentionally delay packets to shape traffic and enforce rate limits.

Two other concepts are crucial: starvation and bufferbloat. Starvation happens when a low-priority flow never gets service because higher-priority flows continuously consume the link. Bufferbloat is the excessive queuing delay caused by overly large buffers combined with naive First-In-First-Out (FIFO) scheduling, a problem that modern algorithms like Fair Queuing and Controlled Delay (CoDel) were specifically designed to solve.

2. How It Works

Most packet scheduling architectures follow a common pipeline: classification, enqueuing, scheduling, and transmission. When a packet arrives at a router, the classifier examines its header fields and, based on configured policies like Differentiated Services Code Point (DSCP) or access control lists, maps it to a specific queue. Each queue may have its own buffer limit and drop policy, such as Tail Drop or Random Early Detection (RED). The scheduler then runs in a tight loop, selecting one queue at a time and dequeuing a packet for transmission on the wire.

The theoretical foundation for fair scheduling comes from the idealized model of Generalized Processor Sharing (GPS). GPS assumes traffic is infinitely divisible like fluid, allowing all backlogged flows to be served simultaneously in proportion to their weights. If flow i has weight w_i, it receives service at a rate of (w_i / sum(w_j)) * link_capacity. While GPS is impossible to implement with discrete packets, it serves as the gold standard for fairness. Practical packet-by-packet algorithms like Weighted Fair Queuing (WFQ) attempt to emulate GPS by computing a virtual finish time for each packet and transmitting packets in order of increasing finish time.

This emulation relies on the concept of virtual time. Virtual time advances at a rate inversely proportional to the number of backlogged flows, tracking the progress of the idealized GPS system. When a packet of length L arrives for flow i, its virtual finish time is calculated as F = max(V(t), F_prev) + L / w_i, where V(t) is the current virtual time and F_prev is the finish time of the previous packet from the same flow. By always picking the packet with the smallest F, WFQ provides near-perfect fairness and delay bounds, but at the cost of computationally expensive sorted queue operations.

The Scheduling Loop and Drop Decisions

In contrast, round-robin based algorithms avoid virtual time entirely. Deficit Round Robin (DRR) assigns each queue a quantum proportional to its weight and a deficit counter. The scheduler visits queues in a circular order, adding the quantum to the deficit counter. If the packet at the head of the queue is smaller than the deficit counter, it is transmitted and the deficit is decremented by the packet size; otherwise, the scheduler moves to the next queue. This simple mechanism achieves long-term fairness without sorting, making it highly efficient for high-speed routers.

Scheduling is tightly coupled with active queue management (AQM). Even the best scheduler cannot prevent latency if queues are allowed to grow unbounded. Algorithms like RED, CoDel, and PIE monitor queue length or sojourn time and proactively drop or mark packets (using Explicit Congestion Notification) to signal congestion to TCP senders before buffers overflow. This interaction between scheduling for ordering and AQM for congestion control is what keeps the Internet stable and responsive.

3. Implementation

Translating scheduling theory into code reveals the trade-offs between fairness, complexity, and performance. Below are four canonical implementations in Python that illustrate the spectrum from simple to sophisticated. Note that these are simplified simulations; production routers implement these in hardware ASICs or highly optimized C for line-rate performance.

The first example is the simplest baseline: First-In-First-Out (FIFO). While not a fair scheduler, it is the default in many switches and is important to understand as a point of comparison.

from collections import deque

class FIFOScheduler:
    def __init__(self, buffer_size=100):
        self.queue = deque()
        self.buffer_size = buffer_size
        self.dropped = 0

    def enqueue(self, packet):
        # packet is a dict: {'id': int, 'flow': str, 'size': int}
        if len(self.queue) >= self.buffer_size:
            self.dropped += 1
            return False  # Tail drop
        self.queue.append(packet)
        return True

    def dequeue(self):
        if not self.queue:
            return None
        return self.queue.popleft()

# Usage
fifo = FIFOScheduler(buffer_size=3)
for p in [{'id': 1, 'flow': 'A', 'size': 500}, {'id': 2, 'flow': 'B', 'size': 500}]:
    fifo.enqueue(p)
print(fifo.dequeue())  # Returns packet 1, regardless of flow

Next is Strict Priority (SP) scheduling, which is used for ultra-low-latency traffic like network control packets or voice. It always serves the highest priority queue that has packets, which is simple but can starve lower priorities.

import heapq

class StrictPriorityScheduler:
    def __init__(self, num_priorities=3):
        # Lower number = higher priority. 0 is highest.
        self.queues = {i: deque() for i in range(num_priorities)}
    
    def enqueue(self, packet, priority):
        # priority 0..num_priorities-1
        self.queues[priority].append(packet)

    def dequeue(self):
        # Scan from highest to lowest priority
        for prio in sorted(self.queues.keys()):
            if self.queues[prio]:
                return self.queues[prio].popleft()
        return None

# Usage: Voice (prio 0) always beats Video (prio 1) and Best-Effort (prio 2)
sp = StrictPriorityScheduler(num_priorities=3)
sp.enqueue({'id': 10, 'flow': 'bulk'}, priority=2)
sp.enqueue({'id': 11, 'flow': 'voice'}, priority=0)
print(sp.dequeue()['flow'])  # 'voice' - starves bulk if voice is continuous

Weighted Fair Queuing provides the GPS emulation. It requires a priority queue (min-heap) keyed by virtual finish time, which is the source of its O(log n) complexity.

import heapq

class WFQScheduler:
    def __init__(self, weights):
        # weights: dict flow_id -> weight
        self.weights = weights
        self.heap = []  # (virtual_finish_time, packet)
        self.virtual_time = 0.0
        self.last_finish = {flow: 0.0 for flow in weights}

    def enqueue(self, packet, arrival_time):
        flow = packet['flow']
        size = packet['size']
        weight = self.weights.get(flow, 1)
        
        # Virtual start time is max of current virtual time and flow's last finish
        start_time = max(self.virtual_time, self.last_finish[flow])
        finish_time = start_time + (size / weight)
        self.last_finish[flow] = finish_time
        
        heapq.heappush(self.heap, (finish_time, packet))

    def dequeue(self):
        if not self.heap:
            return None
        finish_time, packet = heapq.heappop(self.heap)
        # Virtual time advances to the finish time of packet being served
        self.virtual_time = finish_time
        return packet

# Usage: Flow A weight 2 gets twice the bandwidth of Flow B weight 1
wfq = WFQScheduler(weights={'A': 2, 'B': 1})
wfq.enqueue({'id': 1, 'flow': 'A', 'size': 1500}, arrival_time=0)
wfq.enqueue({'id': 2, 'flow': 'B', 'size': 1500}, arrival_time=0)
# Packet from A will have finish_time 750, B will have 1500, so A served first

Finally, Deficit Round Robin (DRR) achieves weighted fairness with O(1) per-packet work, making it ideal for high-speed implementations.

from collections import deque

class DRRScheduler:
    def __init__(self, weights, quantum_base=1500):
        self.queues = {flow: deque() for flow in weights}
        self.weights = weights
        self.quantum = {flow: w * quantum_base for flow, w in weights.items()}
        self.deficit = {flow: 0 for flow in weights}
        self.flow_list = list(weights.keys())
        self.current_idx = 0

    def enqueue(self, packet):
        self.queues[packet['flow']].append(packet)

    def dequeue(self):
        # Try to find a packet to send in one full round
        for _ in range(len(self.flow_list)):
            flow = self.flow_list[self.current_idx]
            if not self.queues[flow]:
                self.current_idx = (self.current_idx + 1) % len(self.flow_list)
                continue
            
            self.deficit[flow] += self.quantum[flow]
            packet_size = self.queues[flow][0]['size']
            
            if packet_size <= self.deficit[flow]:
                self.deficit[flow] -= packet_size
                # Keep index on same flow to allow sending multiple packets if deficit allows
                return self.queues[flow].popleft()
            else:
                # Not enough deficit, move to next flow
                self.current_idx = (self.current_idx + 1) % len(self.flow_list)
        
        return None  # No packet could be sent this round

# Usage: DRR fairly shares link without sorting
drr = DRRScheduler(weights={'A': 2, 'B': 1}, quantum_base=1000)
drr.enqueue({'id': 1, 'flow': 'A', 'size': 800})
drr.enqueue({'id': 2, 'flow': 'B', 'size': 800})
drr.enqueue({'id': 3, 'flow': 'A', 'size': 800})
print(drr.dequeue()['id'])  # 1 (A, deficit 2000)
print(drr.dequeue()['id'])  # 2 (B, deficit 1000)

4. Step-by-Step Example

To make the abstract concrete, let us walk through a Weighted Fair Queuing example with two flows competing for a 10 Mbps link. Flow A is a video conference with weight 3, and Flow B is a file transfer with weight 1. Both flows have 1500-byte packets (12000 bits) arriving at time t=0. The link can transmit one 1500-byte packet in 1.2 ms (12000 bits / 10,000,000 bps).

We initialize virtual time V=0. For Flow A, the first packet P1 (size 1500) gets a finish time F_A1 = max(0, 0) + 1500/3 = 500. For Flow B, packet P2 gets F_B1 = max(0, 0) + 1500/1 = 1500. The scheduler's heap contains [(500, P1), (1500, P2)], so P1 is dequeued first. Virtual time advances to 500. The transmission of P1 takes 1.2 ms of real time.

While P1 is transmitting, two more packets arrive at t=0.5 ms: P3 for Flow A and P4 for Flow B. P3's finish time is F_A2 = max(V=500, F_A1=500) + 500 = 1000. P4's finish time is F_B2 = max(V=500, F_B1=1500) + 1500 = 3000. Note how Flow B's second packet is penalized because its first packet had a large finish time, preserving fairness. The heap is now [(1000, P3), (1500, P2), (3000, P4)]. The next packet to be transmitted is P3 from Flow A, even though P2 arrived earlier. This demonstrates how WFQ enforces weights: Flow A gets two packets served before Flow B gets its first, approximating its 3:1 weight advantage.

DRR Walkthrough for the Same Scenario

Using DRR with quantum_base=1500, quanta are Q_A=4500 and Q_B=1500. Deficit counters start at 0. Round 1: Flow A gets deficit 4500, packet P1 (1500) is <= 4500, so it is sent and deficit becomes 3000. The scheduler stays on Flow A, but no more A packets are queued, so it moves to Flow B. Flow B gets deficit 1500, packet P2 (1500) is sent, deficit becomes 0. Round 2: Flow A gets another 4500 (deficit=7500), sends P3, deficit=6000. Flow B gets 1500, sends P4, deficit=0. Over two rounds, Flow A sent 3000 bytes and Flow B sent 3000 bytes, but because Flow A's quantum is 3x larger, it will continue to sustain 3x the throughput over a longer interval if both flows remain backlogged. This shows DRR's long-term proportional fairness without any sorting.

This example highlights a key difference: WFQ makes fine-grained, packet-by-packet fair decisions based on virtual time, providing tight delay bounds for the high-weight flow. DRR makes coarser, round-based decisions that are computationally cheaper but can introduce slightly higher jitter for latency-sensitive flows within a round.

5. Complexity Analysis

The performance of a packet scheduler is measured not just by its fairness, but by its per-packet computational overhead and memory requirements. At 100 Gbps, a router must make a scheduling decision every few nanoseconds, so even logarithmic factors matter immensely.

FIFO and Strict Priority are O(1) for both enqueue and dequeue, requiring only a simple queue operation. DRR is also O(1) amortized, as each packet is examined at most once per round and deficit accounting is constant time. WFQ and its variants like Worst-case Fair Weighted Fair Queuing (WF2Q) are more expensive due to the heap. Enqueue requires an O(log N) heap insertion where N is the number of queued packets, and dequeue requires an O(log N) extraction. For a router with 100,000 queued packets, this can be a significant bottleneck, which is why hardware implementations use specialized calendar queues or pipelined heaps.

Space complexity is generally O(N) for all algorithms, where N is the total number of buffered packets. However, the constant factors differ. FIFO needs one queue. DRR and WFQ need per-flow state: DRR stores a deficit counter and quantum per flow (O(F) where F is number of flows), while WFQ stores per-flow virtual finish times and a global heap. For core routers handling millions of flows, per-flow state can consume megabytes of fast SRAM, making memory efficiency a critical design constraint.

In practice, the choice is a trade-off between fairness guarantees and implementation cost. If you need strict delay bounds for VoIP, the O(log N) cost of WFQ is justified. If you need to fairly share a 400 Gbps link among thousands of tenants with minimal jitter, the O(1) simplicity of DRR or its variant Elastic Round Robin (ERR) is preferred. Modern programmable data planes like P4 often implement a hybrid: a small number of WFQ classes (e.g., 8) with DRR within each class.

6. Variations and Optimizations

The classic algorithms have spawned numerous optimized variants to address specific weaknesses. One major limitation of WFQ is that its virtual time can become complex when flows have variable packet sizes and weights change dynamically. Self-Clocked Fair Queuing (SCFQ) simplifies this by using the finish time of the packet currently in service as the virtual time, eliminating the need to simulate GPS. While less precise, SCFQ is easier to implement in hardware.

For round-robin schedulers, the original DRR can suffer from unfairness when packet sizes vary widely, as a flow with large packets may need to wait multiple rounds. Deficit Round Robin with Carry-over and variants like Smoothed Round Robin (SRR) and Elastic Round Robin (ERR) address this by allowing deficit to carry over more intelligently or by interleaving packets to reduce burstiness. For example, SRR spreads a flow's packets evenly across rounds rather than sending them back-to-back, which reduces jitter for downstream queues.

Another critical optimization is hierarchical scheduling. Class-Based Weighted Fair Queuing (CBWFQ) and Hierarchical Token Bucket (HTB) allow administrators to create a tree of classes. For instance, a root class might divide bandwidth 60% to Enterprise traffic and 40% to Guest traffic; within Enterprise, 70% goes to VoIP and 30% to Data. This is implemented by nesting schedulers: a top-level DRR or WFQ schedules among major classes, and each class internally runs its own scheduler. Linux's Traffic Control (tc) subsystem is a prime example, supporting HTB, HFSC, and FQ-CoDel hierarchies.

Active Queue Management Integration

Modern schedulers are rarely deployed without AQM. Fair Queuing with Controlled Delay (FQ-CoDel) is a landmark combination that solves both fairness and bufferbloat. It creates a separate queue per flow (using hashing), schedules them with DRR, and applies CoDel's sojourn-time-based dropping independently to each queue. If a flow's queue delay exceeds 5ms for 100ms, CoDel drops a packet to signal congestion. This isolates bufferbloat to the offending flow without harming latency-sensitive flows. Similarly, CAKE (Common Applications Kept Enhanced) builds on FQ-CoDel with additional features like host fairness, DiffServ handling, and overhead compensation for DSL links.

For wireless and 5G networks, channel-aware schedulers like Proportional Fair (PF) are essential. Unlike wired schedulers that assume a fixed link rate, PF considers the instantaneous radio channel quality of each user. It schedules the user with the highest ratio of current achievable rate to average throughput, maximizing overall cell throughput while maintaining long-term fairness. This is a departure from pure fair queuing, optimizing for spectral efficiency in a time-varying medium.

7. Real-World Applications

Packet scheduling algorithms are not academic curiosities; they are embedded in every layer of the digital infrastructure. Their impact is most visible where resources are scarce and performance guarantees are critical.

In enterprise and ISP routers from vendors like Cisco, Juniper, and Arista, CBWFQ and Low Latency Queuing (LLQ) are standard. LLQ is a hybrid that combines a strict priority queue for voice/video with WFQ for other classes. A typical configuration might reserve 30% of a WAN link as a priority queue for VoIP (policed to prevent starvation), while the remaining 70% is shared via CBWFQ among business-critical, bulk, and scavenger traffic. This ensures a CEO's video call is never degraded by an employee's large backup.

In data centers, scheduling is crucial for multi-tenancy and congestion control. Google's Andromeda virtual network and Microsoft's Azure use weighted fair queuing in their virtual switches (vSwitches) to enforce per-tenant bandwidth caps and prevent noisy neighbors. At the fabric level, switches use Data Center Quantized Congestion Notification (DCQCN) and DRR to manage incast congestion, where many servers simultaneously reply to one client. Without fair scheduling, incast can cause catastrophic throughput collapse.

Operating systems also rely heavily on packet scheduling. The Linux kernel's qdisc (queuing discipline) layer includes FQ-CoDel as the default since kernel 4.12, dramatically improving desktop latency under load. Bufferbloat tests show that FQ-CoDel can reduce ping latency from 1000ms to 20ms during a bulk upload, simply by fairly scheduling flows and controlling queue delay. Similarly, Apple's Network Extension framework and Windows' packet scheduler use fair queuing to isolate applications.

Even web servers and databases use analogous scheduling. Nginx and Envoy proxy use weighted round-robin to distribute requests among backend servers, which is conceptually identical to packet scheduling but at the application layer. Database query schedulers prioritize short OLTP transactions over long OLAP queries using similar fair queuing principles to meet latency SLOs.

8. Comparison with Alternatives

Choosing a scheduler requires understanding the fundamental trade-offs between simplicity, fairness, and guarantees. No single algorithm is optimal for all scenarios. The table below provides a comprehensive feature comparison to guide selection.

The key takeaway is that FIFO should be avoided on any congested link where fairness matters. Strict Priority should only be used with a policer that limits the high-priority rate to a small fraction of link capacity (typically 30-35%) to prevent starvation. WFQ is the gold standard for fairness but is often overkill; DRR provides 95% of the fairness at 10% of the cost, which is why it dominates high-speed hardware. For most software-based systems today, FQ-CoDel or CAKE is the recommended default because it combines the best of both worlds: O(1) fairness and automatic bufferbloat control without manual tuning.

It is also worth comparing scheduling to related but distinct mechanisms: shaping vs. scheduling vs. policing. Shaping delays packets to enforce a rate limit (non-work-conserving), policing drops or marks packets that exceed a rate, while scheduling orders packets that are already queued. A complete QoS architecture often uses all three: a policer at ingress to mark traffic, a hierarchical scheduler in the core to share bandwidth, and a shaper at egress to smooth bursts to the provider's rate.

9. Common Mistakes and Best Practices

Even with a perfect algorithm, misconfiguration can render QoS ineffective or even harmful. One of the most common mistakes is over-provisioning strict priority queues. Engineers, wanting to ensure voice quality, might allocate 50% or more of the link to the priority queue. Under congestion, this starves all other traffic, causing routing protocols to flap and management access to fail. Best practice is to strictly police the priority queue to the minimum needed (e.g., voice requires ~87 kbps per call) and never exceed 33% of link capacity.

Another frequent pitfall is ignoring packet size and link overhead. WFQ and DRR calculations based solely on IP packet size are inaccurate on links with significant per-packet overhead, such as DSL with ATM cell padding or Wi-Fi with large preambles. A 64-byte VoIP packet may consume as much airtime as a 1500-byte packet on Wi-Fi. Advanced schedulers like CAKE include overhead compensation keywords (e.g., `overhead 44 mpu 64`) to account for this, ensuring true fairness at the physical layer. Failing to configure this leads to small-packet flows getting an unfair advantage.

A third mistake is using excessively large buffers in an attempt to prevent drops. This directly causes bufferbloat. A 1000-packet buffer on a 10 Mbps link adds 1.2 seconds of queuing delay (1000 * 1500 * 8 / 10e6). Best practice is to size buffers based on the bandwidth-delay product and to always enable AQM. For most links, a buffer of 100-300 ms of queuing is sufficient; beyond that, dropping is healthier than delaying. Modern best practice is to let FQ-CoDel manage queue length automatically rather than manually tuning buffer sizes.

Design and Monitoring Best Practices

• Classify at the edge, schedule in the core: Perform expensive deep packet inspection and DSCP marking at ingress routers, and use simple DSCP-based scheduling in high-speed core routers to keep the fast path fast.
• Monitor per-queue metrics: Do not just monitor link utilization. Track per-queue drops, queue depth, and sojourn time. A queue that is consistently dropping indicates a need for more bandwidth or a lower weight for that class.
• Test under congestion: QoS policies are invisible when the link is idle. Use tools like iperf3, Flent, or tc-netem to generate congestion and verify that priority traffic maintains low latency and that fairness is as expected.
• Prefer hierarchical models: Instead of flat WFQ with 20 flows, use a 2-level hierarchy: 4 major classes (e.g., Real-Time, Business, Bulk, Scavenger) with DRR/FQ within each class. This is easier to manage and understand.
• Document weights as rates: Instead of abstract weights like 10 and 5, configure schedulers using absolute rates (e.g., 100 Mbps, 50 Mbps) where possible. This makes the intended allocation explicit and avoids errors when adding new classes.

10. Interview Questions

Packet scheduling is a favorite topic in networking and systems interviews for roles at cloud providers, router vendors, and performance engineering teams. Below are common questions with guidance on what interviewers expect.

Q1: Why is FIFO not considered fair, and what is bufferbloat?

Answer: FIFO is not fair because it provides no isolation between flows. A single aggressive flow (e.g., a large TCP transfer) can fill the entire queue, causing packets from other flows to be tail-dropped and to experience huge queuing delays. This is unfair because the aggressive flow gets a disproportionate share of bandwidth and imposes latency on everyone else. Bufferbloat is the resulting pathology where excessively large FIFO buffers, intended to prevent drops, instead cause seconds of delay and make the network unusable for interactive traffic. The solution is fair queuing (to isolate flows) plus AQM like CoDel (to keep queue delay low). Mentioning the classic 2010 bufferbloat paper and Jim Gettys' work shows depth.

Q2: Explain the difference between WFQ and DRR. When would you choose one over the other?

Answer: Both provide weighted fairness, but via different mechanisms. WFQ emulates GPS by computing a virtual finish time for each packet and serving packets in sorted order, giving O(log N) complexity and tight delay bounds. DRR uses deficit counters and round-robin, giving O(1) amortized complexity but coarser delay guarantees. Choose WFQ when you need strict per-packet delay bounds and can afford the sorting cost (e.g., low-speed edge routers with strong QoS SLAs). Choose DRR when you need to scale to very high speeds (100+ Gbps) or many flows, where O(log N) is too expensive and long-term fairness is sufficient (e.g., data center switches, core routers).

Q3: How does FQ-CoDel solve both fairness and bufferbloat simultaneously?

Answer: FQ-CoDel combines two ideas. Fair Queuing (FQ) hashes packets into many sub-queues (typically 1024) based on flow 5-tuple, isolating flows so one flow's queue does not affect another's. It then schedules these sub-queues with DRR for fairness. Controlled Delay (CoDel) runs independently on each sub-queue, tracking the minimum sojourn time (time a packet spends in queue) over a 100ms window. If the minimum stays above a 5ms target, it drops one packet and increases the drop frequency. This signals TCP to slow down before the queue grows large. Together, they ensure each flow gets its fair share and no flow can build a bloated queue that harms latency.

Q4: What is starvation and how do schedulers prevent it?

Answer: Starvation occurs when a low-priority flow never gets service because higher-priority flows continuously use the link. Strict Priority scheduling is vulnerable to this by design. WFQ and DRR prevent starvation by design: every backlogged flow is guaranteed a minimum service rate proportional to its weight/quantum, regardless of other flows' demand. Even if a flow has weight 1 and another has weight 100, the weight-1 flow will still get 1/101 of the link. Hierarchical schedulers also prevent starvation by policing the priority queue. In an interview, discuss the trade-off: strict priority gives the lowest latency for high-priority traffic but risks starvation; fair schedulers guarantee no starvation but add slightly more latency to the highest priority.

Q5: Design a scheduler for a 5G base station that must handle both eMBB (high throughput) and URLLC (ultra-low latency) traffic.

Answer: This is a system design question. A good answer proposes a hierarchical, channel-aware scheduler. At the top level, use strict priority or preemptive scheduling for URLLC: URLLC packets puncture or preempt eMBB transmissions to meet 1ms latency, but with a policer to limit URLLC to e.g., 20% of resources to prevent eMBB starvation. Within eMBB, use Proportional Fair scheduling to maximize cell throughput by exploiting channel diversity while maintaining long-term fairness. Mention practical constraints: scheduling granularity is per Transmission Time Interval (TTI) or mini-slot, need for channel quality feedback (CQI), and the use of network slicing to isolate resources. This shows understanding beyond textbook algorithms to real-world wireless constraints.