Max.Init.Retransmits and ABORT response to INIT

Max.Init.Retransmits and ABORT response to INIT

[Ian Coolidge]

Hello,

With the Linux SCTP implementation, Max.Init.Retransmits is respected
when INIT messages do not receive a response (ie, if SCTP host is
unavailable). However, if a Linux SCTP host is accessible, but has no
SCTP servers listening for incoming connections, it will quickly reply
ABORT. This doesn't trigger the Max.Init.Retransmits logic, so,
retries occur indefinitely.

I looked through RFC 2960 for some guidance here. Both 3.3.7 and 4
were unclear for how this should be handled. I suspect that these
ABORT responses to INIT should count towards Max.Init.Retransmits.

Is there any clarification that I haven't found?

What do the SCTP experts think should happen here?

Thanks
Ian

Re: Max.Init.Retransmits and ABORT response to INIT

[Vlad Yasevich]

On 10/30/2015 08:03 PM, Ian Coolidge wrote:
> Hello,
> 
> With the Linux SCTP implementation, Max.Init.Retransmits is respected
> when INIT messages do not receive a response (ie, if SCTP host is
> unavailable). However, if a Linux SCTP host is accessible, but has no
> SCTP servers listening for incoming connections, it will quickly reply
> ABORT. This doesn't trigger the Max.Init.Retransmits logic, so,
> retries occur indefinitely.
> 
> I looked through RFC 2960 for some guidance here. Both 3.3.7 and 4
> were unclear for how this should be handled. I suspect that these
> ABORT responses to INIT should count towards Max.Init.Retransmits.
> 
> Is there any clarification that I haven't found?
> 
> What do the SCTP experts think should happen here?
> 

An ABORT should terminate the association thus stopping any further
INIT transmissions.  Is that not happening?

-vlad

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

Re: Max.Init.Retransmits and ABORT response to INIT

[Ian Coolidge]

Vlad,

Thanks for the reply,

On Mon, Nov 2, 2015 at 5:07 AM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 10/30/2015 08:03 PM, Ian Coolidge wrote:
>> Hello,
>>
>> With the Linux SCTP implementation, Max.Init.Retransmits is respected
>> when INIT messages do not receive a response (ie, if SCTP host is
>> unavailable). However, if a Linux SCTP host is accessible, but has no
>> SCTP servers listening for incoming connections, it will quickly reply
>> ABORT. This doesn't trigger the Max.Init.Retransmits logic, so,
>> retries occur indefinitely.
> An ABORT should terminate the association thus stopping any further
> INIT transmissions.  Is that not happening?

Thanks for the clarification on the intended behavior.
Do you think that the general abort specification fully defines that behavior?

In my case, it seems like after the abort is received, 65s later,
another INIT attempt is made,
and it repeats indefinitely. I have ruled out application layer
triggering of this by strace -p on the process which owns the client
socketfd,
it is doing no sockopt or connect calls, so I think it is related to
the Linux implementation.