QoS fundamentals: delay, jitter, loss, the bandwidth-delay product and the three QoS models

What QoS actually controls

Every router and switch port has a queue. When packets arrive faster than the outgoing link can send them, they wait in the queue, and when the queue is full they are dropped. Quality of service (QoS) is the set of tools that decides which packets wait less and which are dropped first. It only matters when there is congestion, even a short burst lasting a few milliseconds.

Four measurements describe how a network treats traffic:

• Bandwidth: how many bits per second a path can carry.
• Delay (latency): how long a packet takes from sender to receiver.
• Jitter: variation in delay from one packet to the next. Voice and video players buffer to smooth it, but large jitter causes gaps.
• Loss: packets that never arrive. TCP resends them; real-time voice simply loses that piece of audio.

Where delay comes from

Queuing delay is the only part that changes from moment to moment, which is why it causes most jitter.

The bandwidth-delay product

The bandwidth-delay product (BDP) is the amount of data "in flight" on a path: bandwidth multiplied by the round-trip time (RTT). A 100 Mbps path with a 40 ms RTT holds 100,000,000 x 0.04 = 4,000,000 bits, or 500 KB.

It matters because TCP can only send one receive window of data before it must wait for an acknowledgement. If the window is smaller than the BDP, the sender sits idle and the link is never full, however fast it is. With the original 64 KB maximum window and a 40 ms RTT, one TCP session tops out near 13 Mbps. Window scaling (RFC 7323), which modern operating systems use automatically, fixes this. The BDP also guides buffer sizing: buffers much larger than the BDP only add delay.

Tip: when a user says "the new 1 Gbps link to the other office is slow", check the RTT and the TCP window before blaming QoS. One long-distance TCP session may simply be window-limited.

Best effort, IntServ and DiffServ

• Best effort: no QoS. Every packet is treated the same and queued first in, first out. This is how the public internet behaves.
• Integrated Services (IntServ): an application asks for resources using the Resource Reservation Protocol (RSVP), RFC 2205. Each router on the path agrees or refuses, and keeps state for that flow. On shared LAN segments, a Designated Subnet Bandwidth Manager (DSBM) could manage reservations for the segment. IntServ gives firm guarantees but does not scale to thousands of flows, so it is rare for application traffic today. RSVP lives on in MPLS traffic engineering and in some call admission control designs.
• Differentiated Services (DiffServ): packets are marked with a DSCP value near the source, and each hop applies a per-hop behaviour (PHB) to that class. There is no signalling and no per-flow state, so it scales. Almost every enterprise and provider QoS design uses DiffServ.

Real-world example: a clinic's video consultations

A medical clinic started video consultations over a 50 Mbps internet link. Doctors complained that video froze whenever the practice management system synchronised large scan files. The IT contractor measured the link: average use was only 30%, but bursts from the file sync filled the queue for a few seconds at a time, adding over 200 ms of queuing delay and heavy jitter.

Instead of buying a bigger link straight away, the contractor applied DiffServ: video was marked AF41 and given a guaranteed share, and the file sync was marked as low priority. Video calls stayed smooth and the sync finished only slightly later. This shows the core idea: QoS manages short bursts of congestion; it does not replace capacity planning.