4 comments:

  1. I thought that TCP MSS is not negotiated between receiver and sender (see RFC 879). So it can be independent in each direction.
    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)?
    Replies
    1. TCP MSS values: you're absolutely correct. Fixed.

      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...
    2. What a reaction time! Thank you for your fast response.

      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).
  2. Regarding my last question I should have defined it more precisely: the highest MTU
    along the network path supported is 1500 bytes.
Add comment
Sidebar