From owner-freebsd-bugs@FreeBSD.ORG Thu Jan 15 12:08:19 2015 Return-Path: Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F5D3A1C for ; Thu, 15 Jan 2015 12:08:19 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 D07C68AF for ; Thu, 15 Jan 2015 12:08:18 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0FC8IMm052184 for ; Thu, 15 Jan 2015 12:08:18 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 196755] SCTP aborts connections when primary is affected by packetloss but secondary path is clean Date: Thu, 15 Jan 2015 12:08:18 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 9.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: frans.slothouber@gmail.com X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 12:08:19 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196755 Bug ID: 196755 Summary: SCTP aborts connections when primary is affected by packetloss but secondary path is clean Product: Base System Version: 9.3-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: frans.slothouber@gmail.com I have two machines. Each with two network interfaces. The two machines are connected by two separate IP networks. On these machines runs client/server application that sets up an SCTP association between these two machines. The both client and server bind to the two network interfaces (that is IP addresses assigned to them). The client connects to the server, thus setting up two SCTP paths. Every second both client and server send each other a message. If I now introduce packetloss on the network for the primary SCTP path I observe the following behavior: - With low levels of packetloss, <30%, or high levels of packetloss >85%, the association stays intact. - With medium levels of packetloss the association is aborted. Looking at the packetdump, I see that the FreeBSD SCTP stack keeps insists on sending the SACK packets over the primary path, this causes the other side to abort the connections due to an excess of retransmission. These experiments have been carried out with the following change in the default SCTP settings: sysctl -w net.inet.sctp.heartbeat_interval=500 sysctl -w net.inet.sctp.rto_initial=300 sysctl -w net.inet.sctp.rto_min=100 sysctl -w net.inet.sctp.rto_max=500 sysctl -w net.inet.sctp.path_rtx_max=2 sysctl -w net.inet.sctp.assoc_rtx_max=5 The experiments have been conducted with a Linux - FreeBSD combination and a Linux - Linux combination. (With the FreeBSD machine being the server.) The Linux - Linux combination does not show this behaviour. Some background: this behaviour was found while carrying out tests to see if SCTP can be used for a train-signalling network. -- You are receiving this mail because: You are the assignee for the bug.