Date: Thu, 15 Jan 2015 12:08:18 +0000 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 Message-ID: <bug-196755-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-196755-8>