Encapsulation: Data, Segment, Packet, Frame

Start with 100 bytes of application data — a small HTTP request. TCP prepends a header: 20 bytes without options, typically 32 with the timestamp option every modern stack uses. The result is a segment. IP prepends its 20-byte IPv4 header (40 for IPv6); the result is a packet (RFC language: a datagram). Ethernet prepends a 14-byte header — destination MAC, source MAC, EtherType — and appends a 4-byte frame check sequence; the result is a frame. On the wire the NIC also sends an 8-byte preamble and leaves a 12-byte inter-packet gap, which never appear in a capture but do consume line time.

The names are not decoration; they tell you which layer you are talking about. A "lost packet" is an IP-layer statement; a "retransmitted segment" is TCP; a "dropped frame" is the link. tcpdump shows you frames and decodes every nested layer inside.

The arithmetic for 100 bytes of payload: 100 + 20 (TCP) + 20 (IPv4) + 14 (Ethernet) = 154 bytes in the frame, 158 with the FCS, 178 of line time. Overhead is 54 of 154, about 35%. For a full-size segment carrying 1460 bytes the same 54 bytes are 3.6%, which is why bulk transfer is efficient and tiny messages are not — and why TCP tries to coalesce small writes (Nagle’s algorithm) and why HTTP/2 packs many small frames into one segment.

The receiving NIC checks the FCS and drops the frame if it is corrupt — silently; nobody is told. The driver hands the frame up. The link layer checks the destination MAC is its own (or broadcast/multicast) and reads the EtherType to know which handler to call: 0x0800 → IPv4, 0x86DD → IPv6, 0x0806 → ARP. The IP layer validates the header checksum, checks the destination IP is local (otherwise, if forwarding is enabled, it routes the packet onward instead), and reads the protocol field to pick the next handler: 6 → TCP, 17 → UDP, 1 → ICMP. TCP validates its checksum (computed over the segment *and* a pseudo-header with the IP addresses, so a packet delivered to the wrong host fails it), finds the socket by the 4-tuple, and places the 100 bytes in that socket’s receive buffer.

Each layer reads only its own header and one field that says who is next. That is the entire mechanism of demultiplexing: EtherType → protocol → port. When the application calls read(), it receives exactly the 100 bytes it would have received over any other link, on any other network, over any other IP version. It has no way to learn how many headers came and went.

The MTU (maximum transmission unit) is the largest payload a link will carry in one frame: 1500 bytes on standard Ethernet and most Wi-Fi, up to 9000 with jumbo frames inside a data centre, less on tunnels and PPPoE (1492), VPNs (often 1400–1420) and some mobile networks. The IP packet, headers included, must fit in the MTU. So the MSS — the largest TCP payload per segment — is the MTU minus the IP and TCP headers: 1500 − 20 − 20 = 1460 for IPv4, 1500 − 40 − 20 = 1440 for IPv6, and less again with TCP options. Each side announces its MSS in the SYN, and both use the smaller.

A 200 kB HTTP response therefore leaves the server as ~140 segments of 1460 bytes, each in its own IP packet and frame. The receiver reassembles the byte stream from sequence numbers; the application reads it as one continuous body. Segmentation is invisible to HTTP and is the reason TCP is a *byte stream* rather than a message service.

The MSS is only correct if the *whole path* has an MTU of at least 1500. It often does not: a VPN, a tunnel, or a PPPoE link in the middle may be 1400. Something has to give.

IPv4 has a built-in answer: a router facing a smaller-MTU link may fragment the packet into pieces, each with the same identification field and an offset, and the *destination* host reassembles them. It works and it is a bad idea. Every fragment must arrive for the packet to count — lose one of three and TCP retransmits the whole segment, which is fragmented again. Fragments after the first carry no TCP header, so firewalls and NATs cannot classify them and many simply drop them. Reassembly costs the receiver memory and time, and the identification field is only 16 bits, which at high speed wraps quickly enough to mis-reassemble. IPv6 removed the option: IPv6 routers never fragment; only the sending host may, and TCP over IPv6 avoids that too.

The modern approach on both versions is Path MTU Discovery (PMTUD). The sender sets the DF (don’t fragment) bit on IPv4, or simply sends on IPv6. A router that cannot forward the packet drops it and returns an ICMP message — *Fragmentation Needed* (IPv4, type 3 code 4) or *Packet Too Big* (ICMPv6, type 2) — that includes the MTU of the link it could not fit. The sender lowers its path MTU for that destination, re-segments, and carries on. The dependency is the ICMP message getting back.

When a firewall on the path filters ICMP — a common "security" misconfiguration — PMTUD fails silently and you get an MTU black hole: small packets (handshake, small requests, ping) pass, full-size packets vanish, and the connection hangs precisely when the first large response is sent. Linux mitigates this with TCP MSS clamping on routers (rewriting the MSS in the SYN to fit the link) and with *Packetization Layer PMTUD* (RFC 4821), which probes with progressively smaller segments when it detects the pattern of loss. Both exist because the clean mechanism has a single point of failure.