Visual RFC.
ALL RFCs / RFC 1191
Read the RFC ↗
RFC 1191 / CLASSIC IPv4 PATH MTU DISCOVERY

Fit TCP data inside the new limit

03

A new path estimate limits the complete datagram. TCP must also respect the peer’s MSS (Maximum Segment Size: its advertised data limit) and subtract the headers actually sent.

RFC 1191 · § 3.1EXAMPLE
4 / 4
Fit TCP data inside the new limitThe matching feedback lowers cache1500to1280 while the peer MSS remains1460. With IPv4 and TCP headers20bytes each and no options, maximum data is min1460,1280minus40 =1240. Dropped relative data interval[0,1460) becomes[0,1240) and[1240,1460), carried in IP datagrams1280and260. Both fit the example bottleneck; no duplicate retransmission or advertised-MSS rewrite is implied.Packet size and TCP data size are differentLost data: relative interval [0,1460)[0,1240)[1240,1460) · 220 data bytes1240 + 220 = 1460 · no gap or duplicateIP lengths: 1280 and 260bottleneck: 1280 · both fitdeliver fitting datagrams
04
Send the same data within the path limit.

Datagrams 1280 and 260 fit the 1280 bottleneck. A repeated ICMP notification is not another reason to duplicate the same data.

Source for this drawing: RFC 1191 · Read RFC section 3.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Keep peer receive limits and the path’s packet limit separate.

  • In the no-option IPv4/TCP example,20 bytes of IPv4 header plus 20 bytes of TCP header leave PMTU−40 bytes for data. With options, subtract their actual extra space too; this is not a universal 40-byte-overhead rule.
  • TCP must respect the peer’s received MSS even if PMTU allows more. Current RFC 9293 §3.7.1 gives the effective send MSS calculation; if no IPv4 MSS option arrived, the default send MSS is 536, not 1460.
  • A PMTU decrease informs packetization. RFC 1191 §6.4 suggests retransmitting known dropped data promptly or waiting for the normal timer, but warns one MUST NOT retransmit in response to every duplicate Too Big notification. PMTU discovery does not rewrite the MSS already sent to the peer.
DETAILS

Chosen peer MSS 1460, PMTU 1280, and 20+20 headers yield max data 1240. The missing 1460 data bytes are represented as half-open relative ranges[0,1460), not absolute TCP sequence numbers. Splitting into 1240+220 preserves data; the datagrams are 1280 and 260 octets. Sizes shown are allowed bounds, not a claim that both packets are scheduled simultaneously or that congestion control is complete.

Read the RFC section ↗

All chapters in RFC 1191

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗