Subject: [tsvwg] Server is sending INIT- issue in SCTP

From: "Sailabala Lenka" <[email-masked]>
Date: Tue, 15 May 2012 13:06:16 +0300

Hi,

We are facing an issue related to SCTP. Whenever the SCTP server is
restarted, the server behaves properly for some iterations and then for

some iterations it fails to send the packet on wire. Therefore script
timeouts without getting any response.

Here is the detail informations:

We are using  linux version:2.6.9-55.ELsmp

Client is sending INIT to Server, association is completed & data
communication is working fine. Then after hot-swap in Server side,
Server is sending INIT to Client & association is happening as usual.
But for low load (2k LV) data communications is working fine but at high
load value (4k LV) our SCTP server is failed to process the data for
sometime & then process the next data successfully. Like this packet
loss counter is increasing which is not captured in wireshark.

We have found one difference between the 2 INITs (Client sending to
Server) & (Server sending to Client)

Client INIT supports 2 parameters (ECN parameter & Forward TSN supported
parameter) but Server doesn't support.

Is this a kernel issue? 

Thanks,

Sailabala

---

From: Randy Stewart <[email-masked]>
Date: Tue, 15 May 2012 06:58:26 -0400

Sailabala:

I don't see how the client or server supporting ECN or F-TSN would make any
difference. Basically each side (C & S) describe in the INIT/INIT-ACK what
features they support. In this case one side is saying I can do
ECN and F-TSN the other side is not. If both sides do not agree then those
features are disabled.

Now there are always bugs. So its possible there could be an issue (which I kind of doubt). 
To look for ECN you would look in the IP header in any wireshark trace/tcpdump. Use wireshark
to look at the packet and look at the IP header. You can check the Differentiated Services field. In here
you should see ECN: 0x00: Not-ECT (Not ECN-Capable Transport)

If a ECN flag is set then one of the sides is trying to do ECN when the other side did not
declare they understood it. Note that even if a side was doing this, it would not cause
packet loss *unless* a middle box was discarding packets with the ECN mark. Note you would
always see the packet at the sending side with a tcpdump/wireshark however.

For FWD-TSN the application would also have to send partial reliable packets and you would
see FWD-TSN's on the wire.. again the features *should* be disabled if both sides do not
do them, and I don't see how either could cause packet loss. 

Note you mention Version:2.6.9-55.ELsmp for Linux, its seems strange to me that you don't
mention a different version on the other side. After all if one is declaring a different
feature it must be some other version.

This sounds more like a hardware problem with your hot-swap.

R
On May 15, 2012, at 6:06 AM, Sailabala Lenka wrote:

>  
>  
> Hi,
> We are facing an issue related to SCTP. Whenever the SCTP server is restarted, the server behaves properly for some iterations and then for
> some iterations it fails to send the packet on wire. Therefore script timeouts without getting any response.
>  
> Client is sending INIT to Server, association is completed & data communication is working fine. Then after hot-swap in Server side, Server is sending INIT to Client & association is happening as usual. But for low load (2k LV) data communications is working fine but at high load value (4k LV) our SCTP server is failed to process the data for sometime & then process the next data successfully. Like this packet loss counter is increasing which is not captured in wireshark.
>  
> We have found one difference between the 2 INITs (Client sending to Server) & (Server sending to Client)
> Client INIT supports 2 parameters (ECN parameter & Forward TSN supported parameter) but Server doesn’t support.
>  
>  
> Is this a kernel issue?
>  
>  
> Thanks,
> Sailabala
>  

-----
Randall Stewart
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Tue, 15 May 2012 17:09:15 +0200

> Client INIT supports 2 parameters (ECN parameter & Forward TSN supported parameter) but Server doesn’t support.
Most likely it is an issue related to the LKSCTP or the kernel. Not sure.
I don't know why the INITs are different, but you might want to bring up this
issue on the Linux SCTP mailing list.

Best regards
Michael