Client sends messages through one series of ip and receivers answer through another series of ip, after the primary ip is made down and up

Question

In case of SCTP multihoming, the client sends messages through one series of ip and receivers answer through another series of ip, after the primary ip is made down and up.

here I have configured 2 paths, primary path, and secondary path. Initially, all the messages will be transmitted in the primary path. Now im making primary interface down and all the messages will be transmitted in the secondary path.

Once I made the primary interface up, the first transaction is sent via primary path and answer is getting on the secondary path.

This happens only for the 1st transaction after interface made up. from the 2nd transaction, all the messages are going in the primary path and getting the answer back in the primary path itself.

Answer 1

Behaviour in case depends on a few factors, such as:

• What SACK chunk is actually confirming. Whether it is actually the confirmation of the DATA that has been received via primary path, or confirmation for something that has been received previously.
• Whether it is single SACK or SACK bundled with DATA chunks.
• Whether it confirms DATA chunk received via one path or via two paths (e.g. first packet came via your secondary path and another one via primary). In first case according to RFC 4960 chapter 6.4 SACK should be sent via primary path, in the second case behaviour may vary:

An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.

However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received.

• How strictly particular implementation follows RFC. RFC defined that SACK should be sent to the same destination transport address as source address of the received packet. Strictly speaking RFC does not define what source IP address should be used. E.g. if DATA chunk came in IP packet via IP1-IP2 path, according to RFC it is Okay to send SACK via IP3-IP1 ip path.