top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

INIT re-transmission interval behavior in LKSCTP?

0 votes
463 views

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...

posted Jan 27, 2016 by anonymous

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

0 votes

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

Okay but in the end who will do the actual handling of the re-transmission is the kernel. Which kernel are you using?

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...

That's my understanding too, 3, 6, 12.., How many transports do you have?

answer Jan 27, 2016 by Dewang Chaudhary
Similar Questions
+2 votes

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?

+4 votes

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.

+1 vote

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?

+1 vote

I am currently trying to make an association with otter vendor's system. but it is failed. The engineer of peer side requests me to set checksum parameter into INIT Ack. message we sent.

Q1. is it possible to differently set checksum value for each associations on linux-sctp?
Q2.a. If it is possible to set checksum separately, how to set the flag either use or not?
Q2.b. If it is NOT possible, we MUST turn the checksum feature on for whole association? how to do that? I am using lksctp-1.0.10-7 on Linux 2.6.32-432 (RHEL6).

...