top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

LKSCTP tuning on Linux?

+4 votes
724 views

Are the values in /proc/sys/net/sctp/sctp_[rw]mem honored? Or are they overridden by those in /proc/sys/net/core/[rw]mem_*

Furthermore, the kernel documentation states that sctp_wmem has no effect, but makes no such mention for sctp_mem and sctp_rmem.

posted Apr 7, 2014 by Dewang Chaudhary

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button LinkedIn Share Button

Similar Questions
+2 votes
Looking for a formal LKSCTP compliance statement?

Is LKSCTP 100% compliant with the following?

RFC 2960 - SCTP (obsoleted by RFC 4960)
RFC 3309 - SCTP Checksum Change (obsoleted by RFC 4960)
RFC 3758 - SCTP Partial Reliability Extension
RFC 3873 - SCTP MIB
RFC 4460 - SCTP Errata and Issues
RFC 4895 - Authenticated Chunks for SCTP
RFC 4960 - SCTP
RFC 5061 - SCTP Dynamic Address Reconfiguration
RFC 5062 - Security Attacks Against SCTP

Any pointers are welcome?

0 votes
INIT re-transmission interval behavior in LKSCTP?

We are using LKSCTP version 1.0.16 and have configured the SCTP configuration parameters as follows:

SctpInitMaxAttempts : 10
SctpInitRTO : 3000
SctpMinRTO : 1000
SctpMaxRTO : 60000

We observed that SCTP:INIT re-transmission is occurring at interval 6,12,24.., 6,12,24.., 6,12,24....... As per our understanding re-transmission should occur at interval 3,6,12,24..., 3,6,12,24...3,6,12,24... since SctpInitRTO=3000.

Could you please let us know if it is an expected behavior or not. Also why re-transmission interval is not started with 3,6,12,24...

+1 vote
LKSCTP SCTP_PRIMARY_ADDR query

I've got a question about primary SCTP addresses, what it exactly means to be primary.

Consider an association with two addresses (ie. two sockaddr:s were supplied to sctp_connectx()). SCTP starts using the primary path, then after a while the connection goes down. SCTP tries the secondary path, which is functional. After a while the primary path becomes operational again.

Now, as far as we've seen the SCTP stack delivers a SCTP_ADDR_AVAILABLE event, but doesn't revert back to the primary path, which would be desirable to us. We've discovered the SCTP_PRIMARY_ADDR socket option, but looking at the kernel sources the zeroth address specified with sctp_connectx()
is always made the primary one, so there would be no benefit in trying to reinforce the primaryness with SCTP_PRIMARY_ADDR on SCTP_ADDR_AVAILABLE.

In summary, I'd like to know how to tell the SCTP stack to prefer the zeroth address of sctp_connectx() to transmit data whenever its path is available?

...