Network Engineering Stack Exchange is a question and answer site for network engineers. It only takes a minute to sign up.
Sign up to join this community
I've seen most of TCP flows having DF bit set. So any additional overheads like VXLAN can cause can cause TCP packet to be dropped(since df bit set) ? How the TCP MSS will be adjusted dynamically (in absence of PMTUD)? Since PTMU discovery is not common in wild now. In other words will the packet be dropped if network MTU is set to 1500 and MSS derived in server / client will be 1460. (Considering we have additional overhead - VXLAN)
ta,
How the TCP MSS will be adjusted dynamically (in absence of PMTU)?
The MSS is set when the connection is opened; it is not dynamic. It can be different for each end of the connection. A sends its largest segment size it can receive (A's MSS) to B, and B sends its largest segment it can receive (B's MSS) to A. That happens in the three-way handshake, if at all. Not sending the MSS option in the handshake means that any segment payload size can be received.
RFC 793, transmission Control Protocol explains about the MSS:
Maximum Segment Size Option Data: 16 bits
If this option is present, then it communicates the maximum receive segment size at the TCP which sends this segment. This field must only be sent in the initial connection request (i.e., in segments with the SYN control bit set). If this option is not used, any segment size is allowed.
RFC 1191, Path MTU Discovery makes it explicit:
PMTU Discovery does not affect the value sent in the TCP MSS option, because that value is used by the other end of the connection, which may be using an unrelated PMTU value.
It's not only about "additional overheads like VXLAN" - the path MTU can potentially decrease at any hop. The ubiquity of Ethernet lets people forget about that frequently.
Setting IPv4's Don't Fragment flag with TCP segments is a good approach as it's much more efficient (both bandwidth and processing wise) and it also provides a smoother flow to adapt the MSS to the path MTU instead of relying on in-path fragmentation.
However, setting the DF bit requires proper path MTU discovery, and if the decreasing-MTU hop (router) doesn't return a proper Fragmentation required, and DF flag set ICMP message then that might prove difficult. The TCP stack would first need to try a normal retransmit (could be any kind of packet loss) and then (re)discover the path MTU - either by relying on ICMP or by simply probing. Since the actual path may change for any transmitted packet, so can the path MTU. However, the MSS is only dynamically decreased, not increased.
will the packet be dropped if network MTU is set to 1500 and MSS derived in server / client will be 1460. (Considering we have additional overhead - VXLAN)
Yes, any additional overhead or other situation lowering the in-path MTU below the current packet's size makes the router drop the packet when fragmentation isn't possible (IPv4 with DF flag, or IPv6). The router absolutely needs to return a Fragmentation required, and DF flag set to the source but unfortunately that isn't always the case.
PMTUD usually relies on Fragmentation required messaging, but may also require dealing with black hole connections. For instance, a double retransmit without ACK may trigger decreasing the used MSS MMS_S by some amount. If subsequent retransmits are then successfully ACKed, the MMS_S (maximum message size for send, effective MSS derived from path MTU) may decrease permanently for that connection (and could even by cached for that destination). Alternatively, extensive probing may be used - see RFC 4821. Btw, PMTUD has become mandatory for IPv6.
