Frame, Packet, Segment

The previous lesson traced 100 bytes of application data turning into a 158-byte frame, and used three separate names along the way: segment, datagram, frame. These names are not arbitrary; each denotes a specific layer’s data unit.

Pinning down these names is not merely terminological rigor. Each layer has its own size limit, and these limits determine one another. This lesson’s question is how large a piece of data can be at most, and what happens when it exceeds the limit.

Data Unit Per Layer

The unit a layer forms together with its own header is called a protocol data unit (PDU). The naming per layer is as follows:

Layer	Unit name	Contents
Application	Data / message	The byte sequence the application produces
Transport (TCP)	Segment	TCP header + application data
Transport (UDP)	Datagram	UDP header + application data
Internet	Packet / datagram	IP header + transport unit
Link	Frame	Link header + IP packet + trailer
Physical	Bit / symbol	The signal placed on the medium

Two distinctions are especially prone to confusion.

The first is the segment versus datagram distinction. TCP’s unit is the segment; UDP’s unit is the datagram. The difference in name is not an accident: a segment is a slice cut from a byte stream, and its place within the stream is known by its sequence number. A datagram, by contrast, is a self-contained message whose boundaries are preserved. This difference will be taken up in detail in the Transport Layer topic.

The second is the two meanings of the word packet. In the narrow sense, packet is the Network layer’s unit. In the broad sense, it denotes any piece of data traveling over a network — this is the usage in the term “packet switching.” This course uses the terms “packet” or “datagram” for the Network-layer unit; to avoid loose usage, the other layers’ units are referred to by their own names.

Maximum Transmission Unit

The maximum transmission unit (MTU) is the upper limit on the payload a link-layer technology can carry in a single frame. The measure does not include the link header: MTU is the size of the Network-layer packet the frame can carry.

In the common Ethernet implementation, this limit is 1500 bytes. The reason the limit is an upper bound is that the medium is shared: the longer a single frame takes, the longer the devices waiting their turn have to wait. The reason there is also a lower bound is that header overhead becomes intolerable in small frames.

The MTU value can change along a path. A tunnel, since it must reserve room for its own header, lowers the MTU of the connection inside it. The smallest value that holds across the entire path is called the path MTU.

Maximum Segment Size

The maximum segment size (MSS) is the upper limit on the application data a TCP segment can carry. It is derived from the MTU, with the headers subtracted:

$$\text{MSS} = \text{MTU} - \text{IP header} - \text{TCP header}$$

Medium	MTU	IP header	TCP header	MSS
Ethernet, IPv4	1500	20	20	1460
Ethernet, IPv6	1500	40	20	1440
Tunneled connection	1492	20	20	1452

The corresponding limit for UDP is $1500 - 20 - 8 = 1472$ bytes; the UDP header is 8 bytes.

MSS is announced between the two ends when a TCP connection is established: each end tells the other the largest segment size it can accept, and the smaller of the two governs. This announcement lets the sending side produce segments without falling into fragmentation.

When options are used, the TCP header exceeds 20 bytes and MSS shrinks accordingly. With options such as timestamps and selective acknowledgment active, the usable data space narrows.

Fragmentation

An IPv4 packet is fragmented if it is larger than the MTU of the link it must cross. Fragmentation is carried out with three fields in the IP header:

• Identification: The same across all fragments coming from the same original datagram.
• More Fragments flag (MF): 1 in every fragment except the last.
• Fragment offset: Gives which byte, counted from the start of the original payload, this fragment’s payload begins at. Since the field is 13 bits, the offset is counted in 8-byte units; this is why the payload of every fragment except the last must be a multiple of 8.

The program below takes a given payload size and MTU value and computes the fragments.

def fragment(payload_size: int, mtu: int, header: int = 20) -> None:
    """Splits an IPv4 datagram's payload into fragments according to the MTU limit."""
    fragment_payload = (mtu - header) // 8 * 8      # offset must be a multiple of 8 bytes
    offset = 0
    remaining = payload_size
    index = 1
    while remaining > 0:
        this_fragment = min(fragment_payload, remaining)
        remaining -= this_fragment
        print(f"fragment {index}: payload={this_fragment:4d} bytes  "
              f"offset field={offset // 8:3d}  MF={1 if remaining else 0}  "
              f"datagram={this_fragment + header:4d} bytes")
        offset += this_fragment
        index += 1


fragment(4000, mtu=1500)

Output:

fragment 1: payload=1480 bytes  offset field=  0  MF=1  datagram=1500 bytes
fragment 2: payload=1480 bytes  offset field=185  MF=1  datagram=1500 bytes
fragment 3: payload=1040 bytes  offset field=370  MF=0  datagram=1060 bytes

The steps of the calculation can be followed. Since MTU is 1500 and the IP header is 20 bytes, at most $1500 - 20 = 1480$ bytes of payload can be carried per fragment; 1480 is already a multiple of 8. The first fragment starts at byte 0, so its offset field is 0. The second fragment starts at byte 1480: $1480 / 8 = 185$. The third fragment starts at byte 2960: $2960 / 8 = 370$, and it carries the remaining $4000 - 2960 = 1040$ bytes.

The total payload carried is $1480 + 1480 + 1040 = 4000$ bytes, but the total on the wire comes to $1500 + 1500 + 1060 = 4060$ bytes: two extra IP headers have been added.

A smaller MTU value quickly increases the number of fragments:

fragment(4000, mtu=576)

fragment 1: payload= 552 bytes  offset field=  0  MF=1  datagram= 572 bytes
fragment 2: payload= 552 bytes  offset field= 69  MF=1  datagram= 572 bytes
fragment 3: payload= 552 bytes  offset field=138  MF=1  datagram= 572 bytes
fragment 4: payload= 552 bytes  offset field=207  MF=1  datagram= 572 bytes
fragment 5: payload= 552 bytes  offset field=276  MF=1  datagram= 572 bytes
fragment 6: payload= 552 bytes  offset field=345  MF=1  datagram= 572 bytes
fragment 7: payload= 552 bytes  offset field=414  MF=1  datagram= 572 bytes
fragment 8: payload= 136 bytes  offset field=483  MF=0  datagram= 156 bytes

Here, since $576 - 20 = 556$ is not a multiple of 8, the fragment payload has been rounded down to 552.

The Cost of Fragmentation

Fragmentation is undesirable for three reasons.

The cost of loss is multiplied. Fragments can only be reassembled once all of them arrive. If one of eight fragments is lost, the other seven are discarded as well and the original datagram must be resent. Under the assumption of independent loss, if the per-fragment loss probability is $p$, the probability that an $n$-fragment datagram arrives is $(1-p)^n$; for $p = 0.01$ and $n = 8$, this ratio is about $0.923$, meaning datagram loss rises to 7.7%.

The reassembly burden falls on the receiver. Fragments are not reassembled along the path; they are reassembled only at the final destination. The receiver must hold memory and run a timeout while waiting for missing fragments.

The job of intermediate devices gets harder. Only the first fragment carries the Transport-layer header; later fragments have no port number. Mechanisms that decide based on port cannot classify the later fragments.

For this reason, common practice is to avoid fragmentation. The sender sets the don’t fragment (DF) flag in the IP header; when a packet arrives at a link larger than the MTU, the router drops it and returns an error message to the sender. The sender shrinks the segment size based on the MTU value in this message. This cycle is called path MTU discovery, and it will be taken up in detail in the ICMP lesson.

IPv6 has removed fragmentation from routers along the path entirely: if a packet is larger than the MTU, the router does not fragment it, it drops it and reports this. If fragmentation is needed, only the sending endpoint performs it.

Limits on the Example Network

What happens when the client on the enterprise network wants to send a 3000-byte body to 198.51.100.20 is determined by the calculation built in this lesson. If TCP is used, fragmentation never occurs: the Transport layer splits the body itself and produces three segments of $1460 + 1460 + 80$ bytes. Each segment goes out as a separate IP packet, and none of them exceeds the MTU.

If UDP is used, the situation is different: UDP does not split the body, it produces a single 3000-byte datagram, and the job of splitting falls to the IP layer. This is a concrete example of the choice of transport layer directly determining network-layer behavior.

Summary

• Each layer’s data unit is called by a separate name: segment (TCP), datagram (UDP and IP), packet (IP), frame (Link layer).
• MTU is the upper limit on the Network-layer packet a link can carry in a single frame, and it does not include the link header.
• MSS is found by subtracting the IP and TCP headers from the MTU: 1460 bytes for Ethernet and IPv4.
• Fragmentation is carried out with the identification, more-fragments flag, and fragment offset fields; since offset is counted in 8-byte units, the payloads of every fragment except the last must be a multiple of 8.
• A 4000-byte payload splits into three fragments of 1480 + 1480 + 1040 bytes at a 1500-byte MTU; the total on the wire comes to 4060 bytes.
• Fragmentation multiplies the cost of loss; common practice is to avoid it with the don’t-fragment flag and path MTU discovery.

Next Step

This topic defined the shape data takes across the layers. The next topic descends into how these shapes are actually carried. The first stop is the lowest addressing level: how devices sharing the same cable or the same wireless cell find each other, and how a switch decides where to send a given frame. The next lesson takes up the Ethernet frame and the structure of hardware addresses.