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.slothou...@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.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
