From owner-freebsd-transport@freebsd.org Tue Aug 30 14:20:39 2016 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 56C1BBC8190 for ; Tue, 30 Aug 2016 14:20:39 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 38FDBA3E for ; Tue, 30 Aug 2016 14:20:38 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) X-IronPort-AV: E=Sophos;i="5.30,256,1470726000"; d="scan'208";a="140591910" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx144-out.netapp.com with ESMTP; 30 Aug 2016 07:19:13 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 30 Aug 2016 07:19:12 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::a009:cb7a:e519:7347%21]) with mapi id 15.00.1210.000; Tue, 30 Aug 2016 07:19:12 -0700 From: "Cui, Cheng" To: "freebsd-transport@freebsd.org" Subject: Re: question about if a recent Linux patch on window scaling is required in FreeBSD Thread-Topic: question about if a recent Linux patch on window scaling is required in FreeBSD Thread-Index: AQHR/wo9NkI6m8KaqUqM3LcKN+2ax6BhxysA Date: Tue, 30 Aug 2016 14:19:12 +0000 Message-ID: <27FDDABD-4726-41B1-8A49-FF3274F9AAD3@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <62F21041EEC6964AB02E4FBE2E34BC59@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 30 Aug 2016 16:17:28 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.22 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: Tue, 30 Aug 2016 14:20:39 -0000 Refresh this question. Can anyone make a comment? Thanks, --Cheng Cui NetApp Scale Out Networking On 8/25/16, 3:52 PM, "Cui, Cheng" wrote: Hello everyone, =20 I hope this email could reach you well, because I found related discussions about this topic on window scaling and the case of window shrinking (or retraction or loss of precision). And I try to make this question simple. =20 There is a recent Linux patch at receiver side to round-up advertised window due to precision loss of window scaling. It reaches my attention because the same problem could also happen between a pair of Linux and FreeBSD nodes, and I am not aware of any similar patch in FreeBSD yet. =20 The Linux patch is this: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?= id=3D6 07bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723 =20 And I quote some description of the Linux patch below: > If the sender uses up the entire window before it is shrunk, this can > have chaotic effects on the connection. When sending ACKs, > tcp_acceptable_seq() will notice that the window has been shrunk sinc= e > tcp_wnd_end() is before tp->snd_nxt, which makes it choose tcp_wnd_en= d() >as=20 > sequence number. This will fail the receivers checks in tcp_sequence(= ) >however=20 > since it is before it's tp->rcv_wup, making it respond with a dupack. =20 I think the Linux's behavior is right ("ACK-only packets should be sent with the largest in-window sequence number that has ever been sent." re= f: https://www.ietf.org/mail-archive/web/tcpm/current/msg10512.html), it actually chooses "tp->snd_una+tp->snd_wnd" (tcp_wnd_end()) instead of tp->snd_nxt, as it thought tp->snd_nxt is out of window, in case of precision loss which made the receiver's advertise-window smaller. But = at the=20 other side, if the other side is FreeBSD, I think FreeBSD will also fai= l the=20 check since "tp->snd_una+tp->snd_wnd" is before it's tp->rcv_nxt, and ignore=20 the sequence number in the packet. =20 I also sent an email to tcpm@ietf.org asking if this Linux patch is RFC 7323=20 (window scaling part) compliant, but I have not get any reply yet. =20 So my question here is: Is there any recent change in FreeBSD to accommodate the=20 Linux behavior ("tp->snd_una+tp->snd_wnd" as sequence number)? If not, = do we=20 consider to apply the same way as in the Linux patch? =20 Thanks and apologize in advance if I did not do enough research, --Cheng Cui =20 =20 =20 =20 From owner-freebsd-transport@freebsd.org Thu Sep 1 18:37:45 2016 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 47B2FBCBCEF; Thu, 1 Sep 2016 18:37:45 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "mx141.netapp.com", Issuer "Symantec Class 3 Secure Server CA - G4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1B6B1618; Thu, 1 Sep 2016 18:37:44 +0000 (UTC) (envelope-from Cheng.Cui@netapp.com) X-IronPort-AV: E=Sophos;i="5.30,268,1470726000"; d="scan'208";a="141181174" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 01 Sep 2016 11:37:26 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 1 Sep 2016 11:37:22 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::a009:cb7a:e519:7347%21]) with mapi id 15.00.1210.000; Thu, 1 Sep 2016 11:37:22 -0700 From: "Cui, Cheng" To: "freebsd-transport@freebsd.org" CC: "freebsd-net@freebsd.org" Subject: Re: question about if a recent Linux patch on window scaling is required in FreeBSD Thread-Topic: question about if a recent Linux patch on window scaling is required in FreeBSD Thread-Index: AQHR/wo9NkI6m8KaqUqM3LcKN+2ax6BhxysAgANszgA= Date: Thu, 1 Sep 2016 18:37:21 +0000 Message-ID: <2FE246D5-C2F4-4D67-963F-3B7A083CE4BD@netapp.com> References: <27FDDABD-4726-41B1-8A49-FF3274F9AAD3@netapp.com> In-Reply-To: <27FDDABD-4726-41B1-8A49-FF3274F9AAD3@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 01 Sep 2016 19:17:33 +0000 X-BeenThere: freebsd-transport@freebsd.org X-Mailman-Version: 2.1.22 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: Thu, 01 Sep 2016 18:37:45 -0000 Add freebsd-net to increase the size of audience.=20 Thanks, --Cheng Cui NetApp Scale Out Networking On 8/30/16, 10:19 AM, "Cui, Cheng" wrote: Refresh this question. Can anyone make a comment? =20 Thanks, --Cheng Cui NetApp Scale Out Networking =20 =20 On 8/25/16, 3:52 PM, "Cui, Cheng" wrote: =20 Hello everyone, =20 I hope this email could reach you well, because I found related discussions about this topic on window scaling and the case of wind= ow shrinking (or retraction or loss of precision). And I try to make t= his question simple. =20 There is a recent Linux patch at receiver side to round-up advertis= ed window due to precision loss of window scaling. It reaches my atten= tion because the same problem could also happen between a pair of Linux = and FreeBSD nodes, and I am not aware of any similar patch in FreeBSD y= et. =20 The Linux patch is this: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm= it/?id=3D6 07bfbf2d55dd1cfe5368b41c2a81a8c9ccf4723 =20 And I quote some description of the Linux patch below: > If the sender uses up the entire window before it is shrunk, this= can > have chaotic effects on the connection. When sending ACKs, > tcp_acceptable_seq() will notice that the window has been shrunk = since > tcp_wnd_end() is before tp->snd_nxt, which makes it choose tcp_wn= d_end() >as=20 > sequence number. This will fail the receivers checks in tcp_seque= nce() >however=20 > since it is before it's tp->rcv_wup, making it respond with a dup= ack. =20 I think the Linux's behavior is right ("ACK-only packets should be = sent with the largest in-window sequence number that has ever been sent.= " ref: https://www.ietf.org/mail-archive/web/tcpm/current/msg10512.html), = it actually chooses "tp->snd_una+tp->snd_wnd" (tcp_wnd_end()) instead = of tp->snd_nxt, as it thought tp->snd_nxt is out of window, in case of precision loss which made the receiver's advertise-window smaller. = But at the=20 other side, if the other side is FreeBSD, I think FreeBSD will also= fail the=20 check since "tp->snd_una+tp->snd_wnd" is before it's tp->rcv_nxt, a= nd ignore=20 the sequence number in the packet. =20 I also sent an email to tcpm@ietf.org asking if this Linux patch is= RFC 7323=20 (window scaling part) compliant, but I have not get any reply yet. =20 So my question here is: Is there any recent change in FreeBSD to accommodate the=20 Linux behavior ("tp->snd_una+tp->snd_wnd" as sequence number)? If n= ot, do we=20 consider to apply the same way as in the Linux patch? =20 Thanks and apologize in advance if I did not do enough research, --Cheng Cui =20 =20 =20 =20 =20 =20 =20 =20