D12430

[Sepherosa Ziehau]

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 <tuexen at freebsd.org> 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
> _______________________________________________
> freebsd-transport at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-transport
> To unsubscribe, send any mail to "freebsd-transport-unsubscribe at freebsd.org"



-- 
Tomorrow Will Never Die