Ethernet MTU and TCP MSS: How Much Room Is Left for Application Data?

Start by identifying what the quoted bytes include

A supplier proposing larger Ethernet MTUs for an AI data path may put a port rate, a packet size and an application message size on the same page. They describe different properties. A rate in Gb/s describes bits per unit time. A limit in bytes describes the size of a particular object. Neither a connector type nor the rate beside it supplies the missing packet-length definition.

For the calculations here, MTU means the permitted size of the IP packet, including its IP header. RFC 791's IPv4 Total Length field counts the header and data together. The TCP header and TCP data sit inside that IP packet.

Ethernet framing is a surrounding boundary. RFC 894's Frame Format description places the IP header and IP data inside the Ethernet data field; even Ethernet padding, when needed, is outside the IP packet's length. Thus an IP MTU and a complete Ethernet frame length cannot be substituted for each other.

Before comparing two offers, establish whether each length means an IP packet, an Ethernet frame or TCP data. If the supplier quotes a frame limit, ask which fields it counts and how that relates to the proposed IP packet. For a tunnel or another encapsulation, the corresponding inner and outer boundaries also need to be identified before doing any subtraction.

References: [R2][R4]

A larger endpoint limit does not establish the path limit

RFC 1191 defines path MTU as the smallest MTU among the hops on a particular path. Consider an invented path with hop IP-packet limits of 9,000, 1,500 and 9,000 bytes. Its path MTU is 1,500 bytes. Raising only the first value would leave that minimum unchanged.

This makes the scope of a supplier's evidence decisive. A statement that one adapter supports a 9,000-byte IP MTU concerns that endpoint. A statement that a specified sender-to-receiver path supports 9,000-byte IP packets concerns the complete path. The second claim needs evidence covering the actual endpoints, intervening path and encapsulation conditions.

Treat those as fictional claim types, not confirmations that a real installation supports either value. A family-level feature listing cannot establish the complete-path claim. The response should identify the equipment and software to which its evidence applies, the path covered and when it was qualified.

Path scope also matters after an equipment purchase: RFC 1191 notes that routing changes can change the path MTU. Evidence for one route does not automatically qualify another. The buyer's decision is whether the supplied evidence covers the intended communication path, rather than which isolated device advertises the largest number.

References: [R3]

Advertised MSS and the effective send limit are different

An MSS option in a SYN segment advertises the receiver's limit in TCP data bytes, rather than the length including the TCP header. Record the direction; it is not a route measurement.

RFC 9293, section 3.7.1, distinguishes the remote MSS from the effective send MSS. Sending must respect both the remote MSS and the IP layer's transmission limit, with the applicable header adjustments. The advertised-value calculation subtracts fixed IP and TCP headers from the effective MTU, excluding options. The sender then reduces TCP data for the options actually included in a packet.

That distinction explains why an advertised value can exceed the TCP data fitting a particular packet. RFC 9293 is the August 2022 TCP specification, STD 7, and obsoletes RFC 6691.

References: [R1]

Work the 1,500 → 1,460 → 1,448 → 1,424 byte example

Stipulate an IPv4 packet budget of 1,500 bytes that fits the chosen path, a 20-byte IPv4 header without options and a 20-byte TCP base header. Also stipulate a received MSS of 1,460 bytes and no smaller sending constraint for this illustration. There is no tunnel. These are teaching assumptions for a possible full packet, not observations from a network.

With no TCP options, the space available for TCP data is 1,500 − 20 − 20 = 1,460 bytes. The 1,500 bytes already include both headers. Subtracting Ethernet framing from this stipulated IP budget would mix the surrounding frame with the packet it carries.

Now add exactly 12 bytes to the TCP header for options, including any padding within that added space. The TCP header occupies 32 bytes, so the available TCP data is 1,500 − 20 − 32 = 1,448 bytes. The fixed-header advertised MSS calculation still gives 1,460; the actual option bytes consume room in this packet.

Finally, invent an application envelope that occupies 24 bytes at the beginning of this packet's TCP data, followed by content. The remaining content space is 1,448 − 24 = 1,424 bytes. The complete IP budget balances as 20 bytes of IPv4 header + 32 bytes of TCP header + 24 bytes of application envelope + 1,424 bytes of content = 1,500 bytes.

The 24 envelope bytes belong to TCP data; they are overhead only from the fictional application's content perspective. They must not be deducted once as application framing and again as a TCP header. This example specifies neither TLS framing nor a universal application stack. Its envelope placement is deliberately stipulated for this one packet, not imposed on every segment.

Read the three resulting quantities according to their boundaries: 1,460 is the fixed-header calculation, 1,448 is the TCP data space after the stated options, and 1,424 is the content space after this invented envelope. A proposal promising 1,460 bytes of content in that same packet would overfill the stated budget by 36 bytes.

References: [R1][R4]

An application message is not a TCP segment

TCP supplies a byte stream. RFC 9293, section 3.7, gives no general correspondence between application writes and TCP segments; section 3.9.1.2 also makes clear that PUSH is not a record marker.

Changing an application's message size therefore changes a different object from an MTU or MSS. A message can span segments, and a segment can contain bytes from multiple writes. The 1,424-byte result above describes available content space under the stipulated placement, not a guaranteed record size.

References: [R1]

Decide what the larger-MTU proposal actually establishes

Ask the supplier to carry one consistent definition through its offer: the local supported IP-packet size, the supported path scope, the receiver's advertised MSS in the relevant direction, and the header and application-framing assumptions behind any content-byte claim. The worked example shows why a single unqualified payload number cannot stand in for all four.

If only one endpoint's 9,000-byte capability is documented, the complete-path question remains open. If a particular path has been qualified, the application-content calculation still needs its own framing assumptions. Evidence can resolve one of these questions while leaving the next unresolved.

A larger allowed packet also does not establish a lower application completion time, unchanged loss behavior or interoperability. The byte arithmetic contains no timing measurements, loss observations or compatibility results. A purchase justified by those outcomes needs evidence for those outcomes.

Use the linked cut-through and store-and-forward article when a supplier also makes a switch-latency claim. Its serialization example addresses the time occupied by a stipulated bit count and explains the timing boundaries needed for a comparison. The calculation here addresses which bytes fit inside a stipulated packet; it supplies no switch-latency result.

Carry any equipment changes into the physical connection plan

If the proposal also changes equipment or physical connections, carry the approved endpoint, assembly and route requirements into the cabling package. Leviathan's structured cabling service can discuss installation, routing, dressing, labeling and physical connection records using customer-furnished or separately sourced materials.

Network configuration, MTU selection and path or application qualification remain with the appointed technical owners. For the physical work, use the service and project-inquiry links below to share the approved connection schedule, specified materials, appointed materials supplier, site constraints and required handoff records. This educational byte-budget explanation does not authorize changes to an operating network.

References: [L1]