From nobody Tue Jun 29 09:11:04 2021 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A066CDBDC60 for ; Tue, 29 Jun 2021 09:11:09 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 4GDdxn39x3z4XyJ for ; Tue, 29 Jun 2021 09:11:09 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 99DFD4000C for ; Tue, 29 Jun 2021 11:11:06 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 843E840010; Tue, 29 Jun 2021 11:11:06 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.2 X-Spam-Score: -1.0 Received: from smtpclient.apple (h-98-128-201-113.A785.priv.bahnhof.se [98.128.201.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 7A5BA4000C; Tue, 29 Jun 2021 11:11:05 +0200 (CEST) Content-Type: text/plain; charset=utf-8 List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Subject: Re: RFC: NFS trunking (multiple TCP connections for a mount From: Peter Eriksson In-Reply-To: Date: Tue, 29 Jun 2021 11:11:04 +0200 Cc: freebsd-net Content-Transfer-Encoding: quoted-printable Message-Id: <362300CE-30DA-4552-A3E4-0F3DFE385B2A@lysator.liu.se> References: To: Rick Macklem X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4GDdxn39x3z4XyJ X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N > I don't understand how multiple TCP connections to the same > server IP address will distribute the load across multiple network > interfaces? > I thought that lagg would have handled this? A lagg typically keeps all data in a TCP stream on a specific lagg = member (depending on how the lagg is set up, unless you select the = =E2=80=9Croundrobin=E2=80=9D option in freebsd - don=E2=80=99t do that = unless you like out-of-order packets=E2=80=A6) Network equipment with laggs typically hash the IP streams over the lagg = members based on MAC addresses (source&target), IP addresses = (source&target) and port numbers.=20 (We have been diagnosing a fun problem locally where we see packet = losses/performance drops over our internal backbone network for certain = combinations of odd/even IP addresses/port numbers when things pass = certain SPB =E2=80=9Crouters=E2=80=9D (which typically hash the streams = over many =E2=80=9Cchannels=E2=80=9D between routers)=E2=80=A6 Fun fun. = :-) I think the multiple NFS TCP streams could make for some nice = performance improvements in certain cases. And it would be a more = generalisation of having multiple streams between two hosts - = one-or-many over IPv4 and one-or-many over IPv6 at the same time. = Windows SMB has a similar feature. Just avoid the Linux NFS mounting deadlock issue with =E2=80=9Cdown=E2=80=9D= servers please :-) - Peter=