D12430

[Michael Tuexen]

> On 22. Sep 2017, at 03:50, Sepherosa Ziehau <sepherosa at gmail.com> wrote:
> 
> 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
Hi Sephe,

I agree, there is no use in taking the received peer MSS into account when
sending the MSS. Let me test your patch and report on D12430.

Best regards
Michael
> 
> 
> 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