The situation I encountered is in Azure. Azure automatically subtracts 42 bytes (NVGRE encap overhead) from the MSS option. The flow is generally like this:
Tcpdump on client side: 13:00:25.099465 IP 10.0.1.5.19614 > 10.0.1.4.12865: Flags [S], seq 2686655391, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 4628516 ecr 0], length 0 13:00:25.102567 IP 10.0.1.4.12865 > 10.0.1.5.19614: Flags [S.], seq 1982641632, ack 2686655392, win 65535, options [mss 1376,nop,wscale 6,sackOK,TS val 872848224 ecr 4628516], length 0 Tcpdump on the server side: 13:00:24.979913 IP 10.0.1.5.19614 > 10.0.1.4.12865: Flags [S], seq 2686655391, win 65535, options [mss 1418,nop,wscale 6,sackOK,TS val 4628516 ecr 0], length 0 13:00:24.981228 IP 10.0.1.4.12865 > 10.0.1.5.19614: Flags [S.], seq 1982641632, ack 2686655392, win 65535, options [mss 1418,nop,wscale 6,sackOK,TS val 872848224 ecr 4628516], length 0 As you can see if we unnecessarily "negotiate" the MSS, the client side will see 1376 as MSS instead of 1418. And I believe this kind of MSS adjustment is quite common in various cloud platform. BTW, as I indicated in the description of the review request, _no_ OSes actually "negotiate" the MSS. Thanks, sephe On Fri, Sep 22, 2017 at 2:47 AM, Michael Tuexen <[email protected]> wrote: > Dear all, > > when FreeBS sends a SYN-ACK, it never sends an MSS larger than the one > received in the SYN. This consideration of the peer's MSS is what the > patch removes. > > Personally, I found this neat although not described in an RFC. The > reasoning could be that the client uses its MTU to deduce the MSS > and you make the assumption that this is symmetric. > > Best regards > Michael > _______________________________________________ > [email protected] mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-transport > To unsubscribe, send any mail to "[email protected]" -- Tomorrow Will Never Die _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-transport To unsubscribe, send any mail to "[email protected]"
