SCTP connect() both ways

SCTP connect() both ways

[David Laight]

When SCTP is used for protocols like M3UA it seems common
to configure both port numbers for a connection (typically
to the same value).

Rather than having one system call connect() and the other
listen(), both systems really want to try to establish the
connection by sending out INIT chunks.

The connection then gets established as soon as the second of the
two systems attempts to establish it.

However if the remote system responds with an ABORT (or maybe
an ICMP error is received) the Linux SCTP stack immediately
reports 'connect failed'.
For these sorts of connections it would be much better if the
received ABORT just increased the retry timer to large value.

Thoughts?

	David

Re: SCTP connect() both ways

[Vlad Yasevich]

On 06/09/2014 05:41 AM, David Laight wrote:
> When SCTP is used for protocols like M3UA it seems common
> to configure both port numbers for a connection (typically
> to the same value).
> 
> Rather than having one system call connect() and the other
> listen(), both systems really want to try to establish the
> connection by sending out INIT chunks.

The correct way to do this is to not used connect() call.
Both systems should do a listen() and then use an implicit
connect by using an sctp_sendmsg() or similar calls to
send the data.

> 
> The connection then gets established as soon as the second of the
> two systems attempts to establish it.
> 
> However if the remote system responds with an ABORT (or maybe
> an ICMP error is received) the Linux SCTP stack immediately
> reports 'connect failed'.
> For these sorts of connections it would be much better if the
> received ABORT just increased the retry timer to large value.
> 
> Thoughts?

We don't know why the remote ABORTED.  There could be a lot of
reasons.  It is up to the application to retry.  This is no
different then receiving an RST in response to a SYN.

-vlad

> 
> 	David
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>