From owner-freebsd-net@freebsd.org Thu Sep 3 23:08:31 2015 Return-Path: Delivered-To: freebsd-net@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 9F51C9CA4FA for ; Thu, 3 Sep 2015 23:08:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 60360117E for ; Thu, 3 Sep 2015 23:08:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5D2089CA4F9; Thu, 3 Sep 2015 23:08:31 +0000 (UTC) Delivered-To: net@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 42C519CA4F7; Thu, 3 Sep 2015 23:08:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F674117D; Thu, 3 Sep 2015 23:08:31 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by pacex6 with SMTP id ex6so4223053pac.0; Thu, 03 Sep 2015 16:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YjXKeJVvXBjsZYIiq4e+ipdI5KoJmu4L8DS62OHxAzs=; b=Qi7USCpL2YEhJOH4q2FS2ztBhQ7mmaHkAHs0T7DnqdUGasEK2f0Sp0I0ZVBSLF+rer 5TLWDn5ndyuhO3ZZBCkkpxfCc8EzzkDksFkz1BcdR1DQL1s2HzNxYA2ywZ5sI30/FFnN GgoquXoCARvFQvGMhvxQfzE8ckmzg4WGpFsZ6/M+tVzJLkC9LL8dqHmg8P32wn0RxXFj imR3HZOzUkmH1wZkTSAZmknkjt/QgfBtZTpdBoyij0pEYzyxKFarohM37+douaiCyrcg 7XLVYKy4tdxPnr4ewe07GLbT+ln7uE1CFTUN9KA673AOvQcyVAFxsdM/mPcXhkFBNmJr qCyw== X-Received: by 10.68.69.70 with SMTP id c6mr1007082pbu.28.1441321710382; Thu, 03 Sep 2015 16:08:30 -0700 (PDT) Received: from [33.167.141.194] ([172.56.33.24]) by smtp.gmail.com with ESMTPSA id dh9sm206055pdb.67.2015.09.03.16.08.29 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Sep 2015 16:08:29 -0700 (PDT) Mime-Version: 1.0 (1.0) Subject: Re: GPL issues around OFED code in FreeBSD 9.1 From: Garrett Cooper X-Mailer: iPhone Mail (12H321) In-Reply-To: <7FF6BFC8-0031-4E40-AB38-75B5FD4EF466@frob.org> Date: Thu, 3 Sep 2015 16:08:28 -0700 Cc: Jack Vogel , "K. Macy" , "net@freebsd.org" , Hrishikesh Keremane , "hackers@freebsd.org" , Vijay Singh Message-Id: References: <5BFB9010-159A-44EE-BB9A-A4E445383AA2@yahoo.com> <7FF6BFC8-0031-4E40-AB38-75B5FD4EF466@frob.org> To: Jeff Meegan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 23:08:31 -0000 > On Sep 3, 2015, at 13:18, Jeff Meegan wrote: > > According to their EULA, it is BSD licensed. > > http://www.mellanox.com/page/mlnx_ofed_eula?mtag=linux_sw_drivers Yes, but the 9.1 version wasn't strictly from Mellanox.. I don't know if I'd use the pre-Mellanox version though, tbh. Thanks, -NGie From owner-freebsd-net@freebsd.org Thu Sep 3 23:32:31 2015 Return-Path: Delivered-To: freebsd-net@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 1080B9CAF13 for ; Thu, 3 Sep 2015 23:32:31 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from mail.strugglingcoder.info (strugglingcoder.info [65.19.130.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7EAF18C; Thu, 3 Sep 2015 23:32:30 +0000 (UTC) (envelope-from hiren@strugglingcoder.info) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPSA id 9F542CCD45; Thu, 3 Sep 2015 16:32:29 -0700 (PDT) Date: Thu, 3 Sep 2015 16:32:29 -0700 From: hiren panchasara To: Lawrence Stewart Cc: freebsd-net@freebsd.org Subject: Re: Value of congestion window (cwnd) when loss is detected Message-ID: <20150903233229.GT68814@strugglingcoder.info> References: <20150903005405.GN68814@strugglingcoder.info> <55E82B59.6000202@freebsd.org> <20150903161651.GQ68814@strugglingcoder.info> <20150903175313.GS68814@strugglingcoder.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="U8v/hV883cEE9JJG" Content-Disposition: inline In-Reply-To: <20150903175313.GS68814@strugglingcoder.info> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2015 23:32:31 -0000 --U8v/hV883cEE9JJG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 09/03/15 at 10:53P, hiren panchasara wrote: > On 09/03/15 at 09:16P, hiren panchasara wrote: > > On 09/03/15 at 09:13P, Lawrence Stewart wrote: > [skip] > > >=20 > > > You want to read up about window inflation during fast recovery in RFC > > > 5681 followed by 3782, and then consult Stevens vol 2 to understand h= ow > > > variables are used for different purposes depending on connection sta= te > > > and which code path was taken (something I greatly dislike and would > > > love to change one day). >=20 > Here is my understanding of these rfcs: > RFC 5681: > 3.2. Fast Retransmit/Fast Recovery > When we detect loss: > 2. When the third duplicate ACK is received, a TCP MUST set ssthresh to > no more than the value given in equation (4). When [RFC3042]is in use, > additional data sent in limited transmit MUST NOT be included in this > calculation. >=20 > ssthresh =3D max (FlightSize / 2, 2*SMSS) <-- equation (4). > In my example, > ssthresh =3D max (14480 / 2, 2*1448) =3D 7240. i.e. 5 packets >=20 > 3. The lost segment starting at SND.UNA MUST be retransmitted and cwnd > set to ssthresh plus 3*SMSS. This artificially "inflates" the > congestion window by the number of segments (three) that haveleft the > network and which the receiver has buffered. >=20 > cwnd =3D (ssthresh + 3*SMSS) > In my example, > cwnd =3D 7240 + 3*1448 =3D 11584, i,e, 8 packets >=20 > RFC 3782: > We either do sack based recovery *or* newreno based recovery. And we do > sack based when TF_SACK_PERMIT is present. > So I don't think this comes into play. Please correct me if that is not t= he > case. >=20 > Stevens vol 2: >=20 > sshthresh: > "When t_dupacks reaches 3 ( tcprexmtthresh ), the value of snd_nxt is > saved in onxt and the slow start threshold ( ssthresh ) is set to one-half > the current congestion window, with a minimum value of two segments." >=20 > snd_cwnd: > The congestion window is set to the slow start threshold plus the number > of segments that the other end has cached. By cached we mean the number > of out-of-order segments that the other end has received and generated > duplicate ACKs for. These cannot be passed to the process at the other > end until the missing segment (which was just sent) is received. >=20 > So, according to this, sshthresh itself is set pretty high i.e. cwnd/2. > And, snd_cwnd =3D sshthresh + cached packets at the other end. >=20 > In my example, when server realizes loss, cwnd is 17377 i.e. 12 packets. > Half of that is 6 packets. And cached packets is 2 because the dup acks > we got were for 'ack 2897'. So, according to stevens, snd_cwnd should > have been 6+2 =3D 8 packets. Which matches up to what RFC 5681 suggests. My interpretation of cached packets is wrong here. It should be the packets that receiver *cannot* send up the stack. Receiver told us via SACK (sack 1 {4345:10137}) that it has got at least up to 10137, i.e. 7 packets. And cumulative ack is 2897, i.e. 2 packets. So cached packets at the receiver that it cannot send up comes out to be 5 packets. According to this, the snd_cwnd should be 6(ssthresh) + 5(cached) =3D 11 pa= ckets. Cheers, Hiren --U8v/hV883cEE9JJG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJV6NiNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lTkAH/1wSoKTNbrFEcuZnbWVM/w+D FXeSG/7J/+WuOclkxNHVM2eDG4UBPYB0ANke/E8Cs4+MJ51AotSosprI76bJ58QO wq43P5oWCn22JPq/vEfMQCSF2AF710io2yz8XlTpuiyXpoF5SGbbkSXaaO0CcThX jv52DAtSV+TqQJ86YV2m8GbyEFhxH7bThuA018/WVpLbpk3zdiTPO+ynvw/5Vev/ 0KkBtvqAsTLtcoPDeBf1QbvF0SOGKW5B6oMyHHB3uWdCBU/soDvdXd5/EZJRIIU+ KJa5xE7DECTuuLDgMSZdFDn2LeROeSyXA6RvLx6KnOqRRXheijYhrcrh8w5l0co= =fRAN -----END PGP SIGNATURE----- --U8v/hV883cEE9JJG--