[Bug 196755] SCTP aborts connections when primary is affected by packetloss but secondary path is clean

[bugzilla-noreply at freebsd.org]

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 at FreeBSD.org
          Reporter: frans.slothouber at 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.