An application sends 4 KB UDP datagrams over IPv4 across a 1500-byte MTU path and loses about three times as many messages as the path loses packets; why, and how should it size them?
answer
- one datagram, several IP packets
- all pieces or nothing
- probability compounds per fragment
- only one piece carries ports
- fit the datagram under the path MTU
basics
~20 sA 4,096-byte UDP payload plus its 8-byte header exceeds 1,480 bytes, so IP splits it into three fragments, and losing any one loses the datagram: 1% packet loss becomes about 3% message loss. Size each datagram to fit the path MTU.
solid answer
~50 sThe datagram is 4,104 bytes of IP payload (4,096 plus the 8-byte UDP header). With a 20-byte IPv4 header, a 1500-byte MTU leaves at most 1,480 bytes per packet, so IP sends three fragments. RFC 8085 §3.2 is the key point: losing any single fragment loses the whole datagram, so at 1% independent packet loss the delivery probability is 0.99³, about 97%, roughly three times the loss rate. Worse, only the first fragment carries the UDP header and its ports, so NATs and firewalls that cannot reassemble may drop the rest. The fix RFC 8085 prescribes: do not send datagrams whose IP packets exceed the path MTU. Keep the payload at or under 1,472 bytes on this path, or keep the whole IP packet within 576 bytes over IPv4 or 1,280 over IPv6 when the MTU is unknown, and split application messages so each datagram is independently usable.
go deeper
Recall that a UDP datagram bigger than the path MTU is split by IP into fragments, and that losing any fragment loses the whole datagram.
Compute the fragment count from payload plus 8 against MTU minus the IP header, and show how per-packet loss compounds across fragments.
Diagnose the symptom end to end: compounded loss, first-fragment-only ports and fragment-dropping middleboxes, then apply the RFC 8085 sizing rule and independent application-level splitting.
Set a message-size policy for a UDP protocol that balances efficiency on large-MTU paths against robustness on unknown ones, including the 576 and 1280-byte fallbacks and tunnel overhead.
## The arithmetic of one oversize datagram UDP hands IP one datagram, and IP must deliver it in one packet or split it. Here are the numbers for a 4 KB message over IPv4: 1. UDP payload: **4,096 bytes**. 2. Add the **8-byte UDP header**: the IP payload is **4,104 bytes**. 3. The path MTU is **1,500 bytes**; with the minimum **20-byte IPv4 header**, each packet can carry at most **1,480 bytes** of that payload. 4. 4,104 ÷ 1,480 rounds up to **three fragments**: 1,480 + 1,480 + 1,144 bytes. The same message sent as UDP with a 1,472-byte payload limit would have needed three separate datagrams too, but each would have been independently deliverable. The difference is what happens when a packet is lost. ## Why message loss multiplies RFC 8085 §3.2 states the rule: "The loss of a single fragment results in the loss of an entire fragmented packet, because even if all other fragments are received correctly, the original packet cannot be reassembled and delivered." If each packet is lost independently with probability *p*, a datagram of *n* fragments arrives only when all *n* arrive: | Packet loss *p* | Fragments *n* | Datagram delivered | Datagram lost | |---|---|---|---| | 1% | 1 | 99.0% | 1.0% | | 1% | 3 | 97.0% | 3.0% | | 5% | 3 | 85.7% | 14.3% | | 1% | 45 (a 64 KB datagram) | 63.6% | 36.4% | So the symptom in the question, roughly three times the path's loss rate, is exactly what three fragments predict. The fragments that did arrive are also wasted: they crossed the network, occupied the receiver's reassembly buffer, and are discarded. ## Why some receivers see nothing at all Loss multiplication explains a higher rate; a separate effect can make delivery fail completely for some clients: - Only the **first fragment carries the UDP header**, so only it shows the source and destination ports. The later fragments carry an IP header (addresses, fragment offset) and a slice of data, but no ports. - RFC 8085 §3.2 notes that some **NATs and firewalls drop IP fragments**, because address translation and many filtering policies work on complete packets and not every device implements reassembly. - On such a path, every fragmented datagram fails while small datagrams pass, which looks like "large messages never arrive" rather than "some messages are lost". Over IPv6 the picture changes in one respect: routers never fragment (RFC 8200), so only the sending host can split the datagram, and an oversize packet met in the middle of the path is dropped. The mechanics of fragmentation and how a sender learns the path MTU belong to IP fragmentation and Path MTU Discovery. ## How RFC 8085 says to size datagrams The guideline is a SHOULD NOT: an application **SHOULD NOT send UDP datagrams that result in IP packets that exceed the path MTU**. In practice: - **Know the path MTU** if you can: use the value the IP layer provides, or discover it (RFC 8085 points to PMTUD and its packetization-layer variant). - **Compute the payload budget** as RFC 8085 describes: path MTU minus the IP header (including any IPv4 options or IPv6 extension headers) minus the **8-byte UDP header**. On this path that is **1,472 bytes** over IPv4, **1,452** over IPv6. - **When the MTU is unknown, stay small**: below the effective MTU for sending, which RFC 8085 gives as the smaller of **576 bytes** and the first-hop MTU for IPv4, and **1,280 bytes** for IPv6. - **Split at the application layer**, and do it so that each datagram can be received, and if the application has its own reliability, retransmitted, independently of the others (RFC 8085 §3.2). - **Remember tunnels**: encapsulation eats into the MTU, so a path that is 1,500 bytes at the edge may be smaller in the middle. ## How to reason about it in an interview 1. Do the arithmetic first: payload plus 8, compare with MTU minus the IP header. 2. Name the all-or-nothing reassembly rule and compute the compounded loss. 3. Add the middlebox effect for the "some clients get nothing" variant. 4. Close with the RFC 8085 sizing rule and application-level splitting, rather than a bigger receive buffer or a retry loop, neither of which removes the fragmentation.
- Would raising the receiver's socket buffer size fix the higher message loss in this scenario?No. The loss here happens in the network: a missing fragment means the IP layer can never reassemble the datagram, so it never reaches the socket at all. A larger buffer helps only when datagrams arrive and are dropped because the application reads too slowly. The fix is to stop fragmenting by fitting each datagram under the path MTU.
- If the application does not know the path MTU, what size should it aim for?RFC 8085 §3.2 says to stay below the effective MTU for sending: the smaller of 576 bytes and the first-hop MTU over IPv4, and 1,280 bytes over IPv6, then subtract the IP and 8-byte UDP headers for the payload. It notes that minimum-size datagrams are inefficient on larger-MTU paths, which is a reason to discover the MTU.
- Why does RFC 8085 ask that an application splitting a message make each datagram independently receivable?So one lost datagram does not make its neighbours useless, which would recreate the all-or-nothing loss of IP fragmentation at the application layer. Independent datagrams can be delivered, processed and, if the application has its own reliability, retransmitted one at a time instead of resending the whole message.
Shipping a document as three pages that must all arrive before anyone can read it: if the courier loses one page in a hundred, about three documents in a hundred are unreadable, while three separately readable letters would each fail only one time in a hundred.
saying these in an interview costs you the question
- UDP retransmits a lost fragment, so fragmentation costs only latency
- Each IP fragment carries its own copy of the UDP header
- A bigger receive buffer fixes loss of fragmented UDP datagrams
- 4 KB fits in one packet because the UDP limit is 65,507 bytes
- IPv6 routers fragment oversize UDP datagrams just as IPv4 routers can