From owner-freebsd-transport@freebsd.org Sun Sep 24 17:07:15 2017 Return-Path: Delivered-To: freebsd-transport@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5AA8E2BA79 for ; Sun, 24 Sep 2017 17:07:15 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E45B7F176 for ; Sun, 24 Sep 2017 17:07:15 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.204] (p57BB4EEF.dip0.t-ipconnect.de [87.187.78.239]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id A7D7B71939046; Sun, 24 Sep 2017 19:07:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: D12430 From: Michael Tuexen In-Reply-To: Date: Sun, 24 Sep 2017 19:07:01 +0200 Cc: freebsd-transport@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <6D595B79-5495-40C8-8114-C5824EF3D798@freebsd.org> To: Sepherosa Ziehau X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions of transport level network protocols in FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2017 17:07:15 -0000 > On 22. Sep 2017, at 03:50, Sepherosa Ziehau = wrote: >=20 > 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: >=20 > 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 >=20 > 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 >=20 > 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. >=20 > BTW, as I indicated in the description of the review request, _no_ > OSes actually "negotiate" the MSS. >=20 > 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 >=20 >=20 > On Fri, Sep 22, 2017 at 2:47 AM, Michael Tuexen = wrote: >> Dear all, >>=20 >> 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. >>=20 >> 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. >>=20 >> Best regards >> Michael >> _______________________________________________ >> freebsd-transport@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-transport >> To unsubscribe, send any mail to = "freebsd-transport-unsubscribe@freebsd.org" >=20 >=20 >=20 > --=20 > Tomorrow Will Never Die