Block A · Topics 1–3

Foundations

Why the internet is built in layers, and what the bottom two actually do. Everything above them assumes these work — so when they don't, nothing above makes sense either.

Layers & encapsulation

OSITCP/IPencapsulationMTU

Why it exists

Because nobody could have solved the whole problem at once, and nobody would have agreed on the answer. Layering means the people who invented Wi-Fi didn't have to consult the people who invented HTTP: each layer offers a defined service upward and demands a defined service downward. That's why you can swap Ethernet for Wi-Fi, or IPv4 for IPv6, without rewriting the web.

The two models

#	OSI layer	TCP/IP	Does	Unit	Examples
7	Application	Application	What the user's program means	Message	HTTP, DNS, SMTP
6	Presentation		Encoding, encryption, compression	—	TLS (roughly), JPEG
5	Session		Dialogue management	—	Rarely used as a distinct layer
4	Transport	Transport	Process-to-process delivery, reliability	Segment / datagram	TCP, UDP, QUIC
3	Network	Internet	Host-to-host across networks, routing	Packet	IP, ICMP, BGP
2	Data link	Link	Hop-to-hop on one physical network	Frame	Ethernet, Wi-Fi, ARP
1	Physical	Link	Bits on a wire, radio or fibre	Bit	Cat6, 802.11 radio, optics

Which model to quote

OSI is the teaching model and what exams ask for; TCP/IP is what actually runs. The honest framing, which scores well: "OSI's seven layers are the reference vocabulary, but layers 5 and 6 don't map onto anything real — TLS sits awkwardly between 4 and 7, and in practice engineers say 'L4' meaning transport-level and 'L7' meaning application-level." Being able to say that, rather than reciting seven names, signals you've used it.

Encapsulation and its cost

Ethernet │ IP │ TCP │ ————— your data ————— │ CRC
   14 B    20 B  20 B                          4 B

MTU  Maximum Transmission Unit — the largest FRAME payload the link
     will carry. Ethernet: 1500 bytes.
MSS  Maximum Segment Size — the largest TCP PAYLOAD.
     MSS = MTU − IP header − TCP header = 1500 − 20 − 20 = 1460 bytes

Overhead: 54 bytes of headers before one byte of your data. On a
1460-byte segment that is ~3.6%. On a 1-byte keystroke over SSH it is
5400% — which is why Nagle's algorithm exists (topic 16).

Why MTU matters practically:
· A packet larger than the path MTU must be FRAGMENTED (v4) or dropped
  with an ICMP "too big" (v6, and v4 with DF set).
· VPNs and tunnels add their own headers, shrinking the usable MTU. If
  ICMP is blocked, the sender never learns — the connection completes
  the handshake, then HANGS on the first large packet. This is the
  classic "small requests work, large ones hang" bug, and naming
  PATH MTU DISCOVERY as the cause is a strong interview moment.
· Jumbo frames (9000 B MTU) cut overhead inside a datacentre, but every
  device on the path must agree.

Say this

"Each layer adds a header and treats everything above it as opaque payload, which is why you can replace Ethernet with Wi-Fi without touching HTTP. The three addressing schemes have three different scopes: the MAC address is only meaningful on the current link and is rewritten at every hop; the IP addresses stay the same end to end; the port identifies which process. And the MTU is where layering leaks — a tunnel shrinking the usable MTU while ICMP is blocked gives you a connection that handshakes fine and then hangs on the first big packet."

Link layer & Ethernet

MACswitchARPVLANbroadcast domain

Why it exists

IP knows how to get a packet across the world but has no idea how to move it the last two metres to a specific network card. The link layer handles one hop on one physical network: framing the bits, addressing the right adapter, and detecting corruption.

MAC addresses and frames

MAC address  48 bits, e.g. 3c:22:fb:1a:9e:04
             first 24 bits = OUI (the manufacturer)
             globally unique, burned in (though software can override it,
             which is why MAC-based access control is weak security)
             ff:ff:ff:ff:ff:ff = broadcast, "everyone on this link"

Ethernet frame
  ┌──────────┬──────────┬──────┬───────────────┬─────┐
  │ dst MAC  │ src MAC  │ type │    payload    │ CRC │
  │   6 B    │   6 B    │ 2 B  │  46–1500 B    │ 4 B │
  └──────────┴──────────┴──────┴───────────────┴─────┘
  type: 0x0800 = IPv4 · 0x0806 = ARP · 0x86DD = IPv6 · 0x8100 = VLAN tag

The CRC only DETECTS corruption; the frame is silently dropped, never
repaired. Recovery is someone else's job — TCP's, or the application's.
That is the layering principle in one sentence: each layer detects what
it can and pushes the fixing upward.

Hub vs switch vs router

	Hub	Switch	Router
Layer	1 (physical)	2 (data link)	3 (network)
Decides using	Nothing — repeats to all ports	Destination MAC	Destination IP
Collision domain	One, shared by everyone	One per port	One per port
Broadcast domain	One	One — a switch forwards broadcasts	Separates them — a router does not forward broadcasts
Rewrites headers	No	No (forwards the frame as-is)	Yes — new MAC each hop, decrements TTL
Status	Obsolete	Everywhere	Everywhere

A switch learns by watching: when a frame arrives it records (source MAC → the port it came from) in its MAC address table. If it knows the destination, it forwards to that one port; if not, it floods to every other port and learns from the reply. This is why a switch needs no configuration and why it is dramatically better than a hub — traffic between two machines doesn't disturb anyone else.

The broadcast-domain point interviewers push on

Switches separate collision domains; routers separate broadcast domains. That's why a flat network of 5,000 machines behaves badly no matter how good your switches are — every ARP request reaches all 5,000 hosts, and broadcast traffic grows with the square of the population. The fix is to segment with routers or VLANs. Also worth naming: without STP (Spanning Tree Protocol), a physical loop between switches causes a broadcast storm — frames circulate forever, multiplying at each loop, and the network dies in seconds. Layer 2 has no TTL to stop it, which is precisely why STP exists.

ARP — the glue between IP and MAC

I have an IP address. I need the MAC address to build a frame.

1. Check the ARP cache.                       $ ip neigh
2. Miss → BROADCAST: "who has 192.168.1.7? tell 192.168.1.20"
3. Only the owner replies (unicast): "192.168.1.7 is at 3c:22:fb:1a:9e:04"
4. Cache it (typically ~60s–20min) and send the frame.

Critical detail people get wrong: if the destination IP is OUTSIDE your
subnet, you do NOT ARP for it — you ARP for your DEFAULT GATEWAY and send
the frame there, with the gateway's MAC but the final destination's IP.
Every router along the way rewrites the MAC addresses and leaves the IP
addresses alone. That is the single most useful fact in this topic.

ARP has no authentication at all. Anyone on the link can claim any IP —
ARP SPOOFING, the basis of local man-in-the-middle attacks. Defences are
switch-level: dynamic ARP inspection, DHCP snooping, port security.

VLANs

A VLAN splits one physical switch into several logical networks by adding a 12-bit tag (802.1Q) to frames. Two machines on the same switch but different VLANs cannot reach each other without passing through a router. It buys segmentation without buying hardware — separate broadcast domains, isolation between tenants or departments, and a security boundary that doesn't depend on physical cabling. A trunk port carries multiple tagged VLANs between switches; an access port belongs to one VLAN and sends untagged frames to the end device.

Say this

"The link layer moves a frame across one hop using MAC addresses, and a switch learns which MAC is on which port by watching source addresses, flooding when it doesn't know. ARP is what maps an IP to a MAC — and the key detail is that for an off-subnet destination you ARP for the default gateway, not the destination, so the frame carries the gateway's MAC with the final IP. That's why MAC addresses change at every hop while IP addresses don't. And switches separate collision domains but not broadcast domains, which is why large flat networks need VLANs or routers."

Physical & wireless

bandwidth vs latencyCSMA/CDCSMA/CAhidden terminal

Why it matters beyond trivia

Two reasons this layer earns attention. First, the bandwidth/latency distinction — the most commonly confused pair in networking, and the source of most wrong performance answers. Second, Wi-Fi genuinely behaves differently from wired Ethernet in ways that show up as application bugs.

Bandwidth, latency, throughput

Bandwidth — capacity. Bits per second the link could carry. Width of the pipe.
Latency — delay. Time for one bit to get there. Length of the pipe.
Throughput — what you actually achieve, which is usually neither.
RTT — round-trip time, i.e. 2× one-way latency, and the number that governs handshakes.

Total delay = propagation + transmission + queueing + processing
propagation = distance / (~200,000 km/s in fibre) ≈ 5 µs per km
transmission = packet size / bandwidth
queueing = the variable one, and the source of jitter and bufferbloat

The analogy that lands

Bandwidth is how many lanes the motorway has; latency is how long the motorway is. Adding lanes does nothing for a single car's journey time. So a 10 Gbps link from London to Sydney still has ~250 ms RTT, and a protocol that needs four round trips before sending data will take a second regardless of bandwidth. That's why TLS 1.3 cutting one round trip mattered more than any bandwidth upgrade — and why CDNs work by moving content closer rather than making pipes fatter.

Sharing a medium: CSMA/CD vs CSMA/CA

	CSMA/CD — wired Ethernet	CSMA/CA — Wi-Fi
CD / CA	Collision Detection	Collision Avoidance
Approach	Transmit; if you detect a collision, stop, back off randomly, retry	Listen; if busy wait; wait a random backoff even when idle; require an ACK for every frame
Why the difference	On a wire you can hear your own signal being corrupted	A radio can't listen while transmitting — its own signal swamps the receiver — so collisions can't be detected, only avoided
Status	Effectively obsolete: switched full-duplex Ethernet has no collisions	Very much alive

Why Wi-Fi feels worse than its rated speed

Every frame is acknowledged at layer 2. Wired Ethernet doesn't do this. It roughly halves effective throughput and adds latency variance.
Half duplex and shared. All clients on a channel take turns; your "600 Mbps" is the ceiling for the whole cell, split between everyone.
Rate adaptation. A weak signal drops to a slower, more robust modulation — and one distant slow client occupies airtime that everyone else needs, dragging the whole cell down.
Hidden terminal problem. A and C can both hear the access point but not each other, so both think the medium is free and collide at the AP. RTS/CTS handshaking mitigates it by reserving airtime, at the cost of more overhead.
Interference. 2.4 GHz shares spectrum with microwaves, Bluetooth and every neighbour; 5 GHz has more non-overlapping channels but shorter range.

Where this bites applications

Wi-Fi loss is not congestion, but TCP can't tell the difference: it interprets a lost packet as a congested network and halves its sending rate. So a momentary radio glitch causes a throughput collapse that has nothing to do with the network being busy. This is a real motivation behind loss-tolerant designs and behind congestion controllers like BBR that model bandwidth and RTT directly rather than treating every loss as a congestion signal (topic 15).

Duplex, and multiplexing in one line each

Simplex one direction only · half duplex both directions but not at once (Wi-Fi, old hubs) · full duplex simultaneously both ways (switched Ethernet).
TDM take turns in time · FDM different frequency bands · WDM different wavelengths of light in one fibre · CDM different codes over the same band.

Say this

"Bandwidth is capacity and latency is delay — adding bandwidth does nothing for a transfer bounded by round trips, which is why cutting a handshake round trip matters more than a faster link on a long path. And Wi-Fi differs from Ethernet fundamentally because a radio can't listen while it transmits, so collisions can only be avoided, not detected — hence random backoff even on an idle medium and a layer-2 ACK for every frame. The application-visible consequence is that Wi-Fi loss looks like congestion to TCP, so a radio glitch triggers a rate collapse."