MSS (maximum segment size) is the largest amount of application data, in bytes, that a TCP endpoint is willing to receive in a single segment, not counting the IP and TCP headers. Among transport protocols, MSS is specific to TCP: each side announces its value in the MSS option of the SYN segment during the TCP handshake, and the peer then keeps every segment it sends within that limit.
MSS exists to avoid IP fragmentation. A segment that fits within the path MTU travels as one IP packet; a larger one would have to be fragmented or dropped. On standard Ethernet with an MTU of 1500 bytes, the usual MSS is 1460 bytes for IPv4 and 1440 bytes for IPv6.
How MSS relates to MTU
MSS is derived from the maximum transmission unit (MTU) of the outgoing interface by subtracting the fixed header sizes. The basic formula is MSS = MTU minus IP header minus TCP header, using the minimum header lengths of 20 bytes for IPv4, 40 bytes for IPv6 and 20 bytes for TCP.
| Link or path | MTU (bytes) | MSS with IPv4 | MSS with IPv6 |
|---|---|---|---|
| Standard Ethernet | 1500 | 1460 | 1440 |
| PPPoE broadband | 1492 | 1452 | 1432 |
| WireGuard tunnel (common default) | 1420 | 1380 | 1360 |
| Jumbo frames | 9000 | 8960 | 8940 |
| Minimum IPv6 link | 1280 | Not applicable | 1220 |
The MSS value does not include TCP options such as timestamps. When a connection uses the 12-byte timestamp option, each full-sized segment actually carries fewer data bytes, for example 1448 instead of 1460 on IPv4 Ethernet. The announced MSS stays the same; the sender simply leaves room for options.
How MSS is announced in the TCP handshake
MSS is carried as a four-byte TCP option, kind 2, and is permitted only in segments with the SYN flag set. Each endpoint announces the largest segment it can receive, and the two values are independent: MSS is an announcement, not a negotiation.
- The client sends a SYN with an MSS option based on its own interface MTU.
- The server replies with a SYN-ACK carrying its own MSS option.
- Each side sends segments no larger than the MSS announced by the other side, and no larger than its own path limits.
- If a SYN carries no MSS option, the peer assumes a default of 536 bytes for IPv4 or 1220 bytes for IPv6.
Because the value is chosen from local interface MTUs, neither host knows about a smaller MTU somewhere in the middle of the path. That gap is the source of most MSS-related problems and is covered by path MTU discovery and MSS clamping.
MSS compared with related transport concepts
MSS is frequently confused with neighboring limits that also govern how much data moves at once. The table below separates them.
| Concept | Layer | What it limits | Typical value |
|---|---|---|---|
| MTU | Link and IP | Largest IP packet on a link | 1500 bytes on Ethernet |
| Path MTU | IP | Smallest MTU along a whole path | 1280-1500 bytes on the Internet |
| MSS | TCP | Data bytes in one TCP segment | 1460 bytes for IPv4 on Ethernet |
| TCP window size | TCP | Unacknowledged data in flight | Kilobytes to megabytes |
| Congestion window | TCP | Sender’s own limit to avoid congestion | Grows and shrinks with network conditions |
MSS controls the size of each segment, while the receive window and congestion window control how many segments may be in flight. A large window with a small MSS still works, but it means more packets, more headers and more per-packet processing for the same amount of data. UDP has no MSS; applications such as QUIC choose their own datagram sizes and perform their own path MTU probing.
Path MTU discovery and MSS clamping
Path MTU discovery (PMTUD) lets a sender find the smallest MTU on a path. It sends packets with the DF (do not fragment) flag in IPv4, or relies on the fact that IPv6 routers never fragment, and waits for an ICMP message saying the packet is too big. On receiving it, the sender lowers its effective segment size.
PMTUD fails when firewalls block the necessary ICMP messages. Large segments then disappear silently, a condition called a PMTUD black hole. To protect against it, routers and firewalls at tunnel or PPPoE boundaries often perform MSS clamping: they rewrite the MSS option in passing SYN segments to a lower value that fits the tunnel.
| Situation | Typical clamped MSS | Reason |
|---|---|---|
| PPPoE DSL or fiber | 1452 | PPPoE adds 8 bytes of overhead |
| IPsec site-to-site VPN | About 1350-1380 | ESP headers, padding and authentication |
| GRE tunnel | 1436 | GRE plus outer IP adds 24 bytes |
| Mixed tunnels or uncertain path | 1300-1350 | Safe margin for stacked overheads |
Clamping is a pragmatic workaround rather than a clean design. It affects only TCP, so UDP-based traffic over the same tunnel still needs correct MTU handling or packetization layer path MTU discovery, which probes with real data instead of relying on ICMP.
Symptoms of a wrong MSS
MSS problems produce distinctive and confusing symptoms: small exchanges work, while large transfers stall. A TCP handshake and a short request succeed, but the first full-sized data segment is dropped somewhere along the path.
- Web pages partly load or hang after the first few kilobytes.
- SSH logins succeed but large command output freezes the session.
- File transfers start and then stall at zero throughput.
- Problems appear only over a VPN or a specific broadband connection.
The usual diagnosis is to send pings with the DF flag at decreasing sizes to find the real path MTU, then set the interface MTU or MSS clamp accordingly. Setting MSS too low is safe but wasteful, because each segment carries proportionally more header overhead.
Explained without jargon
When a computer sends a large file, it cuts the file into pieces. MSS is the largest piece the receiving computer agrees to accept in one go, a little like a mailbox slot that only takes envelopes up to a certain size.
Both computers tell each other their slot size at the start of a connection. If some point along the way has an even smaller slot, oversized pieces can get stuck, which is why network devices sometimes lower the agreed size to make sure every piece passes.
A typical use case
A company connects a branch office to headquarters through an IPsec site-to-site VPN over a PPPoE fiber link. Staff report that the intranet loads its login page, but larger pages and file downloads from the central file server hang indefinitely.
A network engineer tests with DF pings and finds that the largest packet that crosses the tunnel is 1400 bytes, while the hosts announce an MSS of 1460. An ICMP filter on an upstream firewall blocks the messages that path MTU discovery needs. The engineer configures MSS clamping to 1360 bytes on the branch router’s tunnel interface. After the change, every TCP connection through the tunnel starts with segments that fit, and the page loads and file transfers complete normally.