From owner-freebsd-net@freebsd.org Tue Jun 27 18:31:10 2017 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 75852D8D796 for ; Tue, 27 Jun 2017 18:31:10 +0000 (UTC) (envelope-from prvs=34432f271=youssef.ghorbal@pasteur.fr) Received: from mx0.pasteur.fr (mx0.pasteur.fr [157.99.45.50]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "Cisco Appliance Demo Certificate", Issuer "Cisco Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CF84E78428 for ; Tue, 27 Jun 2017 18:31:09 +0000 (UTC) (envelope-from prvs=34432f271=youssef.ghorbal@pasteur.fr) Authentication-Results: mx0.pasteur.fr; spf=None smtp.pra=youssef.ghorbal@pasteur.fr; spf=None smtp.mailfrom=youssef.ghorbal@pasteur.fr; spf=None smtp.helo=postmaster@EXCHANGE01.corp.pasteur.fr Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of youssef.ghorbal@pasteur.fr) identity=pra; client-ip=157.99.211.31; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="youssef.ghorbal@pasteur.fr"; x-conformance=sidf_compatible Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of youssef.ghorbal@pasteur.fr) identity=mailfrom; client-ip=157.99.211.31; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="youssef.ghorbal@pasteur.fr"; x-conformance=sidf_compatible Received-SPF: None (mx0.pasteur.fr: no sender authenticity information available from domain of postmaster@EXCHANGE01.corp.pasteur.fr) identity=helo; client-ip=157.99.211.31; receiver=mx0.pasteur.fr; envelope-from="youssef.ghorbal@pasteur.fr"; x-sender="postmaster@EXCHANGE01.corp.pasteur.fr"; x-conformance=sidf_compatible X-IronPort-AV: E=Sophos;i="5.40,271,1496095200"; d="scan'208";a="1463193" Received: from exchange01.corp.pasteur.fr ([157.99.211.31]) by mx0.pasteur.fr with ESMTP/TLS/AES256-GCM-SHA384; 27 Jun 2017 20:31:06 +0200 Received: from EXCHANGE02.corp.pasteur.fr (2002:9d63:d320::9d63:d320) by EXCHANGE01.corp.pasteur.fr (2002:9d63:d31f::9d63:d31f) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.845.34; Tue, 27 Jun 2017 20:31:06 +0200 Received: from EXCHANGE02.corp.pasteur.fr ([fe80::a819:199f:2049:3d20]) by EXCHANGE02.corp.pasteur.fr ([fe80::a819:199f:2049:3d20%18]) with mapi id 15.01.0845.034; Tue, 27 Jun 2017 20:31:05 +0200 From: "Youssef GHORBAL" To: Matt Joras CC: "sthaug@nethelp.no" , "freebsd-net@freebsd.org" , "nparhar@gmail.com" Subject: Re: Sporadic TCP/RST sent to client Thread-Topic: Sporadic TCP/RST sent to client Thread-Index: AQHS66rb2Qoho5P9iUa0cYMOeRPraqI3fpaAgAAbfoCAALjuAIAAG50AgAATvwCAAFQdAIAAF7qA Date: Tue, 27 Jun 2017 18:31:04 +0000 Message-ID: References: <5ABA962E-A90A-4C25-A5A7-EE5CF66FFDD4@pasteur.fr> <20170627.125426.74697078.sthaug@nethelp.no> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [157.99.101.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <58054922E07A124C9EE59E49BCCA74CF@corp.pasteur.fr> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 18:31:10 -0000 [...] > Further, I would argue that round robin is not a valid 802.3ad/802.1AX > algorithm, per how it defines a frame distributor: >=20 > "This standard does not mandate any particular distribution > algorithm(s); however, any distribution algorithm shall ensure that, > when frames are received by a Frame Collector as specified in 5.2.3, > the algorithm shall not cause: > a) Misordering of frames that are part of any given conversation, or > b) Duplication of frames. >=20 > The above requirement to maintain frame ordering is met by ensuring > that all frames that compose a given conversation are transmitted on a > single link in the order that they are generated by the MAC Client; > hence, this requirement does not involve the addition (or > modification) of any information to the MAC frame, nor any buffering > or processing on the part of the corresponding Frame Collector in > order to reorder frames." I tend to agree with you on this point. >> Sure, I was just wondering if the FreeBSD network stack was built with t= he fact that each flow needs to arrive on the same NIC and the system was d= esigned with this assumption in mind or not. >>=20 >> I reported it here, thinking that maybe it's a subtle buggy corner case = and maybe the community was interesting to know about and maybe fix : >>=20 >> - If the stack is working as expected and was built with the assumption = that each incoming flow needs to stick to a NIC during it's lifetime, maybe= documentation needs to be more explicit regarding this situation. In that = case I'll file documentation enhancement bug report. >> - If the stack is misbehaving, maybe help the community identify the roo= t cause and help fixing it >>=20 > As far as I can tell, as Navdeep noted, there's no unexpected > behaviour in your case. "Flows" are a concept that the protocols, in > this case TCP, knows about. The devices themselves (Ethernet cards) > usually have mechanics to make packet delivery decisions based on flow > information (e.g. RSS hashing), but as far as I know that is generally > limited within a single port, so it doesn't really help in the general > case of a lagg. So the fact that it works most of the time is just a "happy" coincidence. B= ut it's not a behaviour to relay on. Right ? Anyway, thank you very much for your help and the clarification on this iss= ue. Youssef=