Respect the path as well as the peer

A large receive advertisement is not proof of a large path MTU.

• RFC 6691 section 5.1 explains that an unnecessarily small advertised MSS can also limit Path MTU Discovery’s ability to find a larger path. Do not solve every path problem by advertising a universally tiny MSS.
• The current TCP effective-send-MSS rule takes the smaller of the peer limit and the IP-layer transmission allowance, then accounts for the actual additional headers (RFC 9293 section 3.7.1).
• In this ordinary IPv4 fixture, the peer advertises 1460 but the chosen IP-layer packet limit is 1280. Subtract 40 fixed-header bytes, take min(1460,1240), then subtract 12 option bytes: at most 1228 data bytes for this packet.
• A 1500-byte candidate cannot pass the selected 1280-byte bottleneck. Here IPv4 DF is set, so the oversized packet is dropped rather than fragmented. A correctly sized 1280-byte example can pass that size gate; delivery is not guaranteed.
• RFC 6691 section 5.4 warns that oversized packets may be fragmented or dropped and that losing fragments can break connections. Actual PMTUD/PLPMTUD probing and failure handling are separate mechanisms, not implemented in this drawing.

The 1280-byte path limit is an already-known illustrative input, not a measured route or a universal IPv4 MTU. Only the packet-size decision is modeled; congestion control, receive windows, retransmission, ICMP authentication and network delivery remain outside the fixture.