Updated: Path MTU Discovery
After describing MTU basics and drawbacks of IP fragmentation, it’s time for more details: Path MTU Discovery (PMTUD) and network implications of using ICMP for PMTUD.
Interested in similar topics? Check out How Networks Really Work webinar.
What about RFC 4821 as a possible solution if firewalls in between are dropping ICMP unreachable messages (PTB)?
The socket option IP_DONTFRAGMENT on Windows just indicates that data should not be fragmented. What you're maybe interested in is the option IP_MTU_DISCOVER on a per socket basis. You could also set it system-widely with the registry entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery to 1. If I remember correctly this registry entry is not available or is set to off.
What are the implications if one side of a connection has IP MTU set to 9000 bytes and the other end has set it to 1500 bytes (both end hosts are not using PMTU discovery)?
RFC 4821: Will mention it in Summary (next week).
Windows: I found this: https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options - the way I read it, PMTUD is enabled by default.
Example: added to the text...
I think on Windows PMTUD is disabled (0) by default. It may depend on the version of Windows. I'm not sure.
In this context it may be worth mentioning TCP/(UDP) segmentation offload. Sometimes we can see huge TCP segments (beyond 60000 bytes) in a capture and wonder how it works.
Google and others try to achieve a performance (throughput) increase by using QUIC (UDP). So it's a fight between TCP and UDP which ends in TCP starvation and UDP dominance.
An other point maybe worth mentioning is the performance impact by using jumbo frames (beyond 9000 bytes).
along the network path supported is 1500 bytes.