Computer Networks

Foundations Of Networking

Measuring a Network

BANDWIDTH how MUCH data per second the link

JrCodex·8 min read

Jr Codex Computer Networks Notes

Level: Beginner Prerequisites: Chapter 4: Network Types and Topologies Time to complete: ~20 minutes


Table of Contents

  1. Bandwidth Is Not Speed
  2. The Four Components of Latency
  3. Throughput
  4. The Bandwidth-Delay Product
  5. Jitter and Packet Loss
  6. Measuring It Yourself
  7. Summary & Next Steps

1. Bandwidth Is Not Speed

The Distinction
─────────────────────────────────────────
  BANDWIDTH   how MUCH data per second the link
              can carry. Bits per second.

  LATENCY     how LONG one bit takes to arrive.
              Milliseconds.

  These are independent. A satellite link can have
  enormous bandwidth and 600ms latency. A direct
  fibre can have modest bandwidth and 2ms latency.
─────────────────────────────────────────
The Analogy Worth Keeping
─────────────────────────────────────────
  A lorry full of hard drives driven across a
  country has ENORMOUS bandwidth — petabytes — and
  terrible latency: eight hours.

  A phone call has tiny bandwidth and excellent
  latency.

  "Faster internet" almost always means more
  BANDWIDTH, and it does nothing for the latency
  that makes a website feel slow.
─────────────────────────────────────────
Which One a User Notices
─────────────────────────────────────────
  Loading a web page needs many small round trips
  — DNS, TCP handshake, TLS handshake, then the
  request (Module 5).

  Each round trip costs LATENCY, not bandwidth.

  Doubling bandwidth from 50 to 100 Mbps barely
  changes page load time. Halving latency from
  100ms to 50ms transforms it.

  This is why CDNs (Module 7, Chapter 2) exist:
  they attack latency by moving content closer, not
  by adding bandwidth.
─────────────────────────────────────────

2. The Four Components of Latency

Where the Milliseconds Go
─────────────────────────────────────────
  1. PROPAGATION DELAY
     Time for the signal to travel the distance.
     distance ÷ (~200,000 km/s in fibre)

     London to New York ≈ 5,600 km ≈ 28ms one way,
     56ms round trip. IRREDUCIBLE — this is physics.

  2. TRANSMISSION DELAY
     Time to push all the bits onto the wire.
     packet size ÷ bandwidth

     1500 bytes on 100 Mbps ≈ 0.12ms

  3. QUEUING DELAY
     Time waiting in a router's buffer behind other
     packets.
     0ms to seconds. THE MOST VARIABLE COMPONENT.

  4. PROCESSING DELAY
     Time for a router to examine headers and
     decide the next hop.
     Microseconds on modern hardware.
─────────────────────────────────────────
def latency_ms(distance_km, packet_bytes, bandwidth_mbps, queue_ms=0):
    propagation = distance_km / 200_000 * 1000            # 200,000 km/s in fibre
    transmission = (packet_bytes * 8) / (bandwidth_mbps * 1e6) * 1000
    return propagation + transmission + queue_ms
 
print(f"{latency_ms(5600, 1500, 100):.2f} ms")            # London→NY: 28.12 ms
print(f"{latency_ms(10, 1500, 100):.3f} ms")              # across town: 0.170 ms
The Consequence of Component 1
─────────────────────────────────────────
  Propagation delay CANNOT be optimised. No
  protocol, no hardware, no money changes the speed
  of light.

  So the only way to reduce it is to REDUCE THE
  DISTANCE — put the server nearer the user.

  That single fact is the entire business case for
  content delivery networks and edge computing.
─────────────────────────────────────────

3. Throughput

Bandwidth vs Throughput
─────────────────────────────────────────
  BANDWIDTH   the theoretical maximum
  THROUGHPUT  what you actually achieve
  GOODPUT     useful application data, excluding
              headers and retransmissions
─────────────────────────────────────────
Why Throughput Is Always Lower
─────────────────────────────────────────
  PROTOCOL OVERHEAD    58 bytes per frame
                       (Chapter 3) — about 4% on
                       full-size frames

  THE BOTTLENECK LINK  end-to-end throughput is
                       the MINIMUM bandwidth along
                       the path. A gigabit
                       connection through a 10 Mbps
                       link gives 10 Mbps.

  TCP BEHAVIOUR        slow start, congestion
                       control and retransmission
                       all reduce it (Module 4)

  THE OTHER END        the server may be slower
                       than your connection

  CONTENTION           you are sharing the link
─────────────────────────────────────────

4. The Bandwidth-Delay Product

The most important number in this chapter, and the least known.

The Definition
─────────────────────────────────────────
  BDP = bandwidth × round-trip time

  It is how much data can be "in flight" on the
  link at once — the capacity of the pipe itself.

  Think of the network as a physical pipe:
  bandwidth is its diameter, latency its length.
  BDP is its VOLUME.
─────────────────────────────────────────
def bdp_bytes(bandwidth_mbps, rtt_ms):
    return (bandwidth_mbps * 1e6 / 8) * (rtt_ms / 1000)
 
print(f"{bdp_bytes(100, 10):>12,.0f} bytes")     # LAN-ish:     125,000
print(f"{bdp_bytes(1000, 80):>12,.0f} bytes")    # transatlantic: 10,000,000
print(f"{bdp_bytes(10, 600):>12,.0f} bytes")     # satellite:      750,000
WHY IT MATTERS
─────────────────────────────────────────
  A sender may only have as much unacknowledged
  data outstanding as its WINDOW allows
  (Module 4, Chapter 4).

  IF THE WINDOW IS SMALLER THAN THE BDP, the sender
  transmits, then STOPS and waits for an
  acknowledgement — leaving the pipe mostly empty.

  Transatlantic 1 Gbps link, 80ms RTT:
    BDP = 10 MB
    A 64 KB window achieves 64KB / 0.08s ≈ 6.4 Mbps

  0.64% of the available bandwidth. The link is
  fine. The window is the bottleneck.

  This is the LONG FAT NETWORK problem, and it is
  why TCP window scaling exists (Module 4,
  Chapter 4).
─────────────────────────────────────────

5. Jitter and Packet Loss

JITTER — variation in latency
─────────────────────────────────────────
  Packets arriving 20ms, 25ms, 18ms, 60ms, 22ms
  apart have jitter even though the average is
  fine.

  Caused mainly by QUEUING DELAY varying with
  congestion.

  WHY IT MATTERS: real-time media. Audio must play
  at a constant rate, so a jittery stream needs a
  JITTER BUFFER — which adds latency deliberately
  to smooth it out.

  For a file download, jitter is irrelevant. For a
  phone call, it is everything.
─────────────────────────────────────────
PACKET LOSS
─────────────────────────────────────────
  Causes:
    CONGESTION       a router's queue is full, so
                     it drops. THE MOST COMMON.
    CORRUPTION       a bit flipped; the frame's
                     checksum fails (Module 2)
    ROUTING          a transient loop or a TTL
                     expiry (Module 3)

  Effects by protocol:
    TCP  detects and retransmits, and INTERPRETS
         loss as congestion, so it slows down
         (Module 4, Chapter 4)
    UDP  does not notice. The application must
         cope, or not care.
─────────────────────────────────────────
The Number That Surprises People
─────────────────────────────────────────
  1% packet loss can reduce TCP throughput by more
  than half.

  Not because 1% of data is lost — because TCP
  reads loss as a congestion signal and reduces its
  sending rate, then rebuilds slowly.

  This is why wifi feels slow long before it looks
  broken: a little loss triggers a large throughput
  penalty (Module 4, Chapter 5).
─────────────────────────────────────────

6. Measuring It Yourself

# LATENCY and LOSS — the first command for any network problem.
ping -c 20 example.com
# rtt min/avg/max/mdev = 12.1/14.3/38.9/4.2 ms
#     └ propagation  └ typical  └ a queuing spike  └ JITTER
 
# PER-HOP latency: where does it jump?
traceroute example.com          # tracert on Windows
mtr example.com                 # continuous; the best of the three
 
# BANDWIDTH between two machines you control.
iperf3 -s                       # on the server
iperf3 -c server.example.com -t 30    # on the client
 
# WHAT THE APPLICATION EXPERIENCES — the breakdown that matters.
curl -w "dns:%{time_namelookup}s connect:%{time_connect}s \
tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n" \
     -o /dev/null -s https://example.com
Reading the curl Breakdown
─────────────────────────────────────────
  dns high         ──► resolver problem
                       (Module 5, Chapter 1)
  connect high     ──► propagation delay; the
                       server is far away
  tls high         ──► extra round trips in the
                       handshake (Module 6, Ch.3)
  ttfb high        ──► the SERVER is slow, not the
                       network
  total >> ttfb    ──► bandwidth or a large
                       response

  This single command separates "the network is
  slow" from "the server is slow" — which are
  investigated completely differently.
─────────────────────────────────────────

7. Summary & Next Steps

Key Takeaways

  • Bandwidth and latency are independent; page load time is dominated by round trips, so latency matters far more than bandwidth for perceived speed.
  • Propagation delay is set by physics and can only be reduced by reducing distance, which is the entire justification for CDNs and edge computing.
  • The bandwidth-delay product is the volume of the pipe; a window smaller than the BDP leaves the link mostly idle regardless of its capacity.
  • One percent packet loss can halve TCP throughput, because TCP interprets loss as congestion and reduces its rate rather than merely resending.

Module 1 Complete — What's Next

You have the vocabulary, the layering model, the encapsulation mechanism and the measurements. Module 2 starts at the bottom of the stack: how bits actually cross a wire, and how a frame gets to the right device on a local network.

Concept Check

  1. Why does doubling your bandwidth barely change how fast a web page feels?
  2. Compute the BDP for a 1 Gbps link with 80ms RTT, and explain what happens with a 64 KB window.
  3. curl reports low connect time and high time-to-first-byte. Where is the problem?

Next Module

Module 2: Physical & Data Link Layers


Jr Codex — 1-on-1 Personalized Coaching | Back to Module Index | Back to Computer Networks Index