Congestion, Latency, Jitter, Packet Loss, and Application Performance Clues
Key Takeaways
- Latency is delay, jitter is variation in delay, packet loss is missing traffic, and congestion is capacity pressure that produces all three.
- High bandwidth does not guarantee low latency; a distant cloud or satellite path can feel slow despite ample capacity.
- Congestion shows as rising output discards, TCP retransmissions, and latency that climbs only under load.
- Application slowness can originate above the network: DNS, TLS, authentication, database locks, storage, or server CPU.
- Baselines and side-by-side comparisons separate normal load from a new performance problem.
Performance Troubleshooting
"Slow" is never a single problem. A sluggish app may stem from a saturated WAN circuit, packet loss on Wi-Fi, high latency to a distant cloud region, DNS delay, a TLS handshake stall, an overloaded server, a database lock, storage latency, or an authentication dependency. Network+ N10-009 rewards reasoning from clues rather than guessing, and several Domain 5 questions hinge on knowing exactly which metric a symptom describes.
Key Performance Terms
| Term | Meaning | Common impact |
|---|---|---|
| Bandwidth | Provisioned or theoretical capacity | Large transfers, aggregate load |
| Throughput | Actual delivered data rate | User-perceived transfer speed |
| Latency | Time to traverse and process the path | Interactive apps feel laggy |
| Jitter | Variation in latency between packets | Voice/video become choppy |
| Packet loss | Packets never arrive | TCP retransmits, UDP quality drops |
| Congestion | Demand exceeds forwarding capacity | Queues, drops, delay, retransmits |
Bandwidth and latency are independent. A 1 Gbps link to a server 80 ms away still feels slow for a chatty, round-trip-heavy application because each request waits a full round trip. Conversely, a low-bandwidth link with 5 ms latency feels snappy for interactive work but chokes on bulk transfers. A useful mental model: bandwidth is how wide the pipe is, latency is how long the pipe is, jitter is how unevenly drops fall through it, and loss is the drops that never make it out the far end.
Congestion and Packet Loss Clues
Congestion is usually time-based, so compare busy hours to quiet hours. A circuit that is fine at 7 a.m. and fails at 10 a.m. is likely oversubscribed or missing Quality of Service (QoS) marking for critical traffic.
| Evidence | Interpretation |
|---|---|
| Output discards rise during peak hours | Egress congestion or queue drops |
| TCP retransmissions increase | Loss, errors, or congestion hitting TCP |
| Choppy audio on calls | Jitter, loss, Wi-Fi retries, or no QoS |
| Video degrades during backups | Competing traffic, insufficient QoS or capacity |
| Latency rises only under load | Queue buildup / buffer pressure |
| CRC and error counters climb | A physical-layer fault, not just congestion |
Note the distinction: discards are drops from full queues (congestion), while errors/CRCs signal a bad cable, duplex mismatch, or failing transceiver. Treat them differently.
Latency and Jitter
Latency hurts round-trip conversations such as remote desktop, database calls, and voice signaling. Jitter hurts real-time streams because packets arrive unevenly; a jitter buffer can absorb some variation but adds its own delay. QoS marks voice (DSCP EF / 46) and video for priority queuing.
| Application type | Most sensitive to |
|---|---|
| Voice over IP | Jitter, loss, latency, QoS marking |
| Video meetings | Bandwidth, jitter, loss, Wi-Fi quality |
| Remote desktop | Latency, packet loss, server load |
| File transfer | Throughput, loss, TCP window scaling |
| Database app | Latency, server processing, query design |
General guidance for clean VoIP: keep one-way latency under ~150 ms, jitter under ~30 ms, and loss under ~1%; exceed those and calls degrade audibly. When backups choke a video meeting, the fix is rarely "more bandwidth" first; it is QoS that marks and queues real-time traffic ahead of bulk transfers so the time-sensitive flow is protected during contention.
Application and Baseline Clues
Not every slow report is the network path. The network may deliver packets quickly while the application waits on authentication, a database query, a third-party API, storage, or server CPU.
| Symptom | Possible non-network cause |
|---|---|
| Page stalls before connecting | DNS or TCP/TLS setup delay |
| Login slow, pages fast afterward | Identity provider, MFA, or directory delay |
| One report slow for everyone | Database query, lock, or app code |
| Uploads slow only from one office | WAN congestion, firewall inspection, ISP path |
| App slow from every location | Server, cloud service, or shared backend |
Read captures by timing: a fast three-way handshake followed by a long wait for the first server byte points up the stack to server or backend processing. Many retransmissions and duplicate ACKs point back down toward loss or congestion.
Baselines and Comparisons
You cannot recognize abnormal without a baseline of interface utilization, error rates, latency to key sites, DNS response time, Wi-Fi retry rate, device CPU/memory, and application response time.
| Comparison | Why it helps |
|---|---|
| Affected vs unaffected user | Narrows client, VLAN, AP, or switch |
| Wired vs wireless | Separates RF from WAN or app |
| App by IP vs by name | Separates DNS from transport/app |
| Peak vs off-peak | Reveals congestion patterns |
| Local app vs cloud app | Separates LAN from WAN/cloud |
Exam Focus
For N10-009, lock in the vocabulary: latency is delay, jitter is delay variation, packet loss is missing packets, and congestion is capacity pressure that produces delay and drops. If the path is clean but server response time is high, do not blame cabling or VLANs; the fault is higher in the stack.
Voice calls become choppy during peak usage. Monitoring shows variable delay between packets but little change in average bandwidth. Which metric best describes the voice problem?
A packet capture shows a fast TCP three-way handshake to a web app, followed by a long delay before the server sends the HTTP response. What does this most strongly suggest?
Which evidence can indicate congestion or packet loss? Select three.
Select all that apply