Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

Hi

I would like to check the behave in LKSCTP.

we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.

We noticed that when remote peer have retry to send the same request
for 4 times, the LKSCTP will initiate an ABORT chunk with reason
"association exceeded its max_retrans count".

We would like to know whether this is the correct behavior? is there
any other option that we can alter in order to avoid the ABORT chunk
being sent?

Thanks

PS

Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

Hi

I would like to check the behave in LKSCTP.

we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.

We noticed that when remote peer have retry to send the same request
for 4 times, the LKSCTP will initiate an ABORT chunk with reason
"association exceeded its max_retrans count".

We would like to know whether this is the correct behavior? is there
any other option that we can alter in order to avoid the ABORT chunk
being sent?

Thanks

PS

Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

Hi

I would like to check the behave in LKSCTP.

we are running DIAMETER message over SCTP, and we have set the
parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.

We noticed that when remote peer have retry to send the same request
for 4 times, the LKSCTP will initiate an ABORT chunk with reason
"association exceeded its max_retrans count".

We would like to know whether this is the correct behavior? is there
any other option that we can alter in order to avoid the ABORT chunk
being sent?

Thanks

PS

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

Hi,

On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
>
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?

I don't recall the RFC saying to send an ABORT, but let me double
check in the mean time.

Hmm, untested, but could you try something like that?

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index fef2acd..5ce198d 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
  		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
  				SCTP_ULPEVENT(event));

-	if (asoc->overall_error_count >= asoc->max_retrans) {
+	if (asoc->overall_error_count >= asoc->max_retrans &&
+	    error != SCTP_ERROR_NO_ERROR) {
  		abort = sctp_make_violation_max_retrans(asoc, chunk);
  		if (abort)
  			sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

Hi,

On 01/23/2015 11:25 AM, Sun Paul wrote:
...
> I would like to check the behave in LKSCTP.
>
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
>
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?

I don't recall the RFC saying to send an ABORT, but let me double
check in the mean time.

Hmm, untested, but could you try something like that?

diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
index fef2acd..5ce198d 100644
--- a/net/sctp/sm_sideeffect.c
+++ b/net/sctp/sm_sideeffect.c
@@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
  		sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
  				SCTP_ULPEVENT(event));

-	if (asoc->overall_error_count >= asoc->max_retrans) {
+	if (asoc->overall_error_count >= asoc->max_retrans &&
+	    error != SCTP_ERROR_NO_ERROR) {
  		abort = sctp_make_violation_max_retrans(asoc, chunk);
  		if (abort)
  			sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> Hi,
> 
> On 01/23/2015 11:25 AM, Sun Paul wrote:
> ...
>> I would like to check the behave in LKSCTP.
>>
>> we are running DIAMETER message over SCTP, and we have set the
>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>
>> We noticed that when remote peer have retry to send the same request
>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>> "association exceeded its max_retrans count".
>>
>> We would like to know whether this is the correct behavior? is there
>> any other option that we can alter in order to avoid the ABORT chunk
>> being sent?
> 
> I don't recall the RFC saying to send an ABORT, but let me double
> check in the mean time.

The RFC is silent on the matter.  The abort got added in 3.8 so
it's been there for a while.


> 
> Hmm, untested, but could you try something like that?
> 
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index fef2acd..5ce198d 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>                  SCTP_ULPEVENT(event));
> 
> -    if (asoc->overall_error_count >= asoc->max_retrans) {
> +    if (asoc->overall_error_count >= asoc->max_retrans &&
> +        error != SCTP_ERROR_NO_ERROR) {
>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>          if (abort)
>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,


This would pretty much stop all ABORTs due to excessive rtx.  Might
as well take the code out :).

I was a bit concerned about this ABORT when it went in.

-vlad

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> Hi,
> 
> On 01/23/2015 11:25 AM, Sun Paul wrote:
> ...
>> I would like to check the behave in LKSCTP.
>>
>> we are running DIAMETER message over SCTP, and we have set the
>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>
>> We noticed that when remote peer have retry to send the same request
>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>> "association exceeded its max_retrans count".
>>
>> We would like to know whether this is the correct behavior? is there
>> any other option that we can alter in order to avoid the ABORT chunk
>> being sent?
> 
> I don't recall the RFC saying to send an ABORT, but let me double
> check in the mean time.

The RFC is silent on the matter.  The abort got added in 3.8 so
it's been there for a while.


> 
> Hmm, untested, but could you try something like that?
> 
> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> index fef2acd..5ce198d 100644
> --- a/net/sctp/sm_sideeffect.c
> +++ b/net/sctp/sm_sideeffect.c
> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>                  SCTP_ULPEVENT(event));
> 
> -    if (asoc->overall_error_count >= asoc->max_retrans) {
> +    if (asoc->overall_error_count >= asoc->max_retrans &&
> +        error != SCTP_ERROR_NO_ERROR) {
>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>          if (abort)
>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,


This would pretty much stop all ABORTs due to excessive rtx.  Might
as well take the code out :).

I was a bit concerned about this ABORT when it went in.

-vlad

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>> ...
>>> I would like to check the behave in LKSCTP.
>>>
>>> we are running DIAMETER message over SCTP, and we have set the
>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>
>>> We noticed that when remote peer have retry to send the same request
>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>> "association exceeded its max_retrans count".
>>>
>>> We would like to know whether this is the correct behavior? is there
>>> any other option that we can alter in order to avoid the ABORT chunk
>>> being sent?
>>
>> I don't recall the RFC saying to send an ABORT, but let me double
>> check in the mean time.
>
> The RFC is silent on the matter.  The abort got added in 3.8 so
> it's been there for a while.

I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
exceeded") added the behaviour.

>> Hmm, untested, but could you try something like that?
>>
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fef2acd..5ce198d 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>                   SCTP_ULPEVENT(event));
>>
>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>> +        error != SCTP_ERROR_NO_ERROR) {
>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
>>           if (abort)
>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>
> This would pretty much stop all ABORTs due to excessive rtx.  Might
> as well take the code out :).
>
> I was a bit concerned about this ABORT when it went in.

So effectively, if I understand the argument from the commit, the
assumption is that the ABORT would never reach the peer anyway, but
is a way for tcpdump users to see on the wire that rtx limit has
been exceeded and since there's not mentioned anything in the RFC
about this, it doesn't break it. Hm.

Sun Paul, what exactly broke in your scenario? Can you be more explicit?

Thanks,
Daniel

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>> ...
>>> I would like to check the behave in LKSCTP.
>>>
>>> we are running DIAMETER message over SCTP, and we have set the
>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>
>>> We noticed that when remote peer have retry to send the same request
>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>> "association exceeded its max_retrans count".
>>>
>>> We would like to know whether this is the correct behavior? is there
>>> any other option that we can alter in order to avoid the ABORT chunk
>>> being sent?
>>
>> I don't recall the RFC saying to send an ABORT, but let me double
>> check in the mean time.
>
> The RFC is silent on the matter.  The abort got added in 3.8 so
> it's been there for a while.

I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
exceeded") added the behaviour.

>> Hmm, untested, but could you try something like that?
>>
>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>> index fef2acd..5ce198d 100644
>> --- a/net/sctp/sm_sideeffect.c
>> +++ b/net/sctp/sm_sideeffect.c
>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>                   SCTP_ULPEVENT(event));
>>
>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>> +        error != SCTP_ERROR_NO_ERROR) {
>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
>>           if (abort)
>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>
> This would pretty much stop all ABORTs due to excessive rtx.  Might
> as well take the code out :).
>
> I was a bit concerned about this ABORT when it went in.

So effectively, if I understand the argument from the commit, the
assumption is that the ABORT would never reach the peer anyway, but
is a way for tcpdump users to see on the wire that rtx limit has
been exceeded and since there's not mentioned anything in the RFC
about this, it doesn't break it. Hm.

Sun Paul, what exactly broke in your scenario? Can you be more explicit?

Thanks,
Daniel

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>>
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>>
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>>
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>>
>> The RFC is silent on the matter.  The abort got added in 3.8 so
>> it's been there for a while.
> 
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
> 
>>> Hmm, untested, but could you try something like that?
>>>
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>                   SCTP_ULPEVENT(event));
>>>
>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>           if (abort)
>>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>
>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>> as well take the code out :).
>>
>> I was a bit concerned about this ABORT when it went in.
> 
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
> 

Additionally I seem to recall BSD sending this type of ABORT for pretty
much the same reason.

-vlad

> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> 
> Thanks,
> Daniel

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>>
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>>
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>>
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>>
>> The RFC is silent on the matter.  The abort got added in 3.8 so
>> it's been there for a while.
> 
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
> 
>>> Hmm, untested, but could you try something like that?
>>>
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>                   SCTP_ULPEVENT(event));
>>>
>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>           if (abort)
>>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>
>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>> as well take the code out :).
>>
>> I was a bit concerned about this ABORT when it went in.
> 
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
> 

Additionally I seem to recall BSD sending this type of ABORT for pretty
much the same reason.

-vlad

> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> 
> Thanks,
> Daniel

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Michael Tuexen]

> On 23 Jan 2015, at 19:30, Vlad Yasevich <vyasevich@gmail.com> wrote:
> 
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
>> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>>> ...
>>>>> I would like to check the behave in LKSCTP.
>>>>> 
>>>>> we are running DIAMETER message over SCTP, and we have set the
>>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>> 
>>>>> We noticed that when remote peer have retry to send the same request
>>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>>> "association exceeded its max_retrans count".
>>>>> 
>>>>> We would like to know whether this is the correct behavior? is there
>>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>>> being sent?
>>>> 
>>>> I don't recall the RFC saying to send an ABORT, but let me double
>>>> check in the mean time.
>>> 
>>> The RFC is silent on the matter.  The abort got added in 3.8 so
>>> it's been there for a while.
>> 
>> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
>> exceeded") added the behaviour.
>> 
>>>> Hmm, untested, but could you try something like that?
>>>> 
>>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>>> index fef2acd..5ce198d 100644
>>>> --- a/net/sctp/sm_sideeffect.c
>>>> +++ b/net/sctp/sm_sideeffect.c
>>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>>                  SCTP_ULPEVENT(event));
>>>> 
>>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>>          if (abort)
>>>>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>> 
>>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>>> as well take the code out :).
>>> 
>>> I was a bit concerned about this ABORT when it went in.
>> 
>> So effectively, if I understand the argument from the commit, the
>> assumption is that the ABORT would never reach the peer anyway, but
>> is a way for tcpdump users to see on the wire that rtx limit has
>> been exceeded and since there's not mentioned anything in the RFC
>> about this, it doesn't break it. Hm.
>> 
> 
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
Yepp.

Best regards
Michael
> 
> -vlad
> 
>> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
>> 
>> Thanks,
>> Daniel
> 
> 

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Michael Tuexen]

> On 23 Jan 2015, at 19:30, Vlad Yasevich <vyasevich@gmail.com> wrote:
> 
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
>> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>>> ...
>>>>> I would like to check the behave in LKSCTP.
>>>>> 
>>>>> we are running DIAMETER message over SCTP, and we have set the
>>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>>> 
>>>>> We noticed that when remote peer have retry to send the same request
>>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>>> "association exceeded its max_retrans count".
>>>>> 
>>>>> We would like to know whether this is the correct behavior? is there
>>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>>> being sent?
>>>> 
>>>> I don't recall the RFC saying to send an ABORT, but let me double
>>>> check in the mean time.
>>> 
>>> The RFC is silent on the matter.  The abort got added in 3.8 so
>>> it's been there for a while.
>> 
>> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
>> exceeded") added the behaviour.
>> 
>>>> Hmm, untested, but could you try something like that?
>>>> 
>>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>>> index fef2acd..5ce198d 100644
>>>> --- a/net/sctp/sm_sideeffect.c
>>>> +++ b/net/sctp/sm_sideeffect.c
>>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>>                  SCTP_ULPEVENT(event));
>>>> 
>>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>>          if (abort)
>>>>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>>> 
>>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>>> as well take the code out :).
>>> 
>>> I was a bit concerned about this ABORT when it went in.
>> 
>> So effectively, if I understand the argument from the commit, the
>> assumption is that the ABORT would never reach the peer anyway, but
>> is a way for tcpdump users to see on the wire that rtx limit has
>> been exceeded and since there's not mentioned anything in the RFC
>> about this, it doesn't break it. Hm.
>> 
> 
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
Yepp.

Best regards
Michael
> 
> -vlad
> 
>> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
>> 
>> Thanks,
>> Daniel
> 
> 

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Neil Horman]

On Fri, Jan 23, 2015 at 01:30:55PM -0500, Vlad Yasevich wrote:
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> > On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> >>> On 01/23/2015 11:25 AM, Sun Paul wrote:
> >>> ...
> >>>> I would like to check the behave in LKSCTP.
> >>>>
> >>>> we are running DIAMETER message over SCTP, and we have set the
> >>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> >>>>
> >>>> We noticed that when remote peer have retry to send the same request
> >>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> >>>> "association exceeded its max_retrans count".
> >>>>
> >>>> We would like to know whether this is the correct behavior? is there
> >>>> any other option that we can alter in order to avoid the ABORT chunk
> >>>> being sent?
> >>>
> >>> I don't recall the RFC saying to send an ABORT, but let me double
> >>> check in the mean time.
> >>
> >> The RFC is silent on the matter.  The abort got added in 3.8 so
> >> it's been there for a while.
> > 
> > I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> > exceeded") added the behaviour.
> > 
> >>> Hmm, untested, but could you try something like that?
> >>>
> >>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> >>> index fef2acd..5ce198d 100644
> >>> --- a/net/sctp/sm_sideeffect.c
> >>> +++ b/net/sctp/sm_sideeffect.c
> >>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
> >>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> >>>                   SCTP_ULPEVENT(event));
> >>>
> >>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
> >>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
> >>> +        error != SCTP_ERROR_NO_ERROR) {
> >>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
> >>>           if (abort)
> >>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >>
> >> This would pretty much stop all ABORTs due to excessive rtx.  Might
> >> as well take the code out :).
> >>
> >> I was a bit concerned about this ABORT when it went in.
> > 
> > So effectively, if I understand the argument from the commit, the
> > assumption is that the ABORT would never reach the peer anyway, but
> > is a way for tcpdump users to see on the wire that rtx limit has
> > been exceeded and since there's not mentioned anything in the RFC
> > about this, it doesn't break it. Hm.
> > 
> 
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
> 
> -vlad
> 
IIRC, BSD is where this patch came from initially.
Neil

> > Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> > 
> > Thanks,
> > Daniel
> 
> --
> 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: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Neil Horman]

On Fri, Jan 23, 2015 at 01:30:55PM -0500, Vlad Yasevich wrote:
> On 01/23/2015 12:10 PM, Daniel Borkmann wrote:
> > On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
> >> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
> >>> On 01/23/2015 11:25 AM, Sun Paul wrote:
> >>> ...
> >>>> I would like to check the behave in LKSCTP.
> >>>>
> >>>> we are running DIAMETER message over SCTP, and we have set the
> >>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> >>>>
> >>>> We noticed that when remote peer have retry to send the same request
> >>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> >>>> "association exceeded its max_retrans count".
> >>>>
> >>>> We would like to know whether this is the correct behavior? is there
> >>>> any other option that we can alter in order to avoid the ABORT chunk
> >>>> being sent?
> >>>
> >>> I don't recall the RFC saying to send an ABORT, but let me double
> >>> check in the mean time.
> >>
> >> The RFC is silent on the matter.  The abort got added in 3.8 so
> >> it's been there for a while.
> > 
> > I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> > exceeded") added the behaviour.
> > 
> >>> Hmm, untested, but could you try something like that?
> >>>
> >>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
> >>> index fef2acd..5ce198d 100644
> >>> --- a/net/sctp/sm_sideeffect.c
> >>> +++ b/net/sctp/sm_sideeffect.c
> >>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
> >>>           sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
> >>>                   SCTP_ULPEVENT(event));
> >>>
> >>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
> >>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
> >>> +        error != SCTP_ERROR_NO_ERROR) {
> >>>           abort = sctp_make_violation_max_retrans(asoc, chunk);
> >>>           if (abort)
> >>>               sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> >>
> >> This would pretty much stop all ABORTs due to excessive rtx.  Might
> >> as well take the code out :).
> >>
> >> I was a bit concerned about this ABORT when it went in.
> > 
> > So effectively, if I understand the argument from the commit, the
> > assumption is that the ABORT would never reach the peer anyway, but
> > is a way for tcpdump users to see on the wire that rtx limit has
> > been exceeded and since there's not mentioned anything in the RFC
> > about this, it doesn't break it. Hm.
> > 
> 
> Additionally I seem to recall BSD sending this type of ABORT for pretty
> much the same reason.
> 
> -vlad
> 
IIRC, BSD is where this patch came from initially.
Neil

> > Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> > 
> > Thanks,
> > Daniel
> 
> --
> 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: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Michael Tuexen]

> On 23 Jan 2015, at 18:10, Daniel Borkmann <dborkman@redhat.com> wrote:
> 
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>> 
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>> 
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>> 
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>> 
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>> 
>> The RFC is silent on the matter.  The abort got added in 3.8 so
>> it's been there for a while.
> 
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
> 
>>> Hmm, untested, but could you try something like that?
>>> 
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>                  SCTP_ULPEVENT(event));
>>> 
>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>          if (abort)
>>>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> 
>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>> as well take the code out :).
>> 
>> I was a bit concerned about this ABORT when it went in.
> 
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
Yepp. It might not reach the peer or it might. If it does it helps
to keep the states in sync. If it doesn't it sometimes helps in
analysing tracefiles. In BSD, we also send it. It is not required,
doesn't harm and is useful in some cases...

Best regards
Michael
> 
> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> 
> Thanks,
> Daniel
> 

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Michael Tuexen]

> On 23 Jan 2015, at 18:10, Daniel Borkmann <dborkman@redhat.com> wrote:
> 
> On 01/23/2015 05:05 PM, Vlad Yasevich wrote:
>> On 01/23/2015 06:50 AM, Daniel Borkmann wrote:
>>> On 01/23/2015 11:25 AM, Sun Paul wrote:
>>> ...
>>>> I would like to check the behave in LKSCTP.
>>>> 
>>>> we are running DIAMETER message over SCTP, and we have set the
>>>> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
>>>> 
>>>> We noticed that when remote peer have retry to send the same request
>>>> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
>>>> "association exceeded its max_retrans count".
>>>> 
>>>> We would like to know whether this is the correct behavior? is there
>>>> any other option that we can alter in order to avoid the ABORT chunk
>>>> being sent?
>>> 
>>> I don't recall the RFC saying to send an ABORT, but let me double
>>> check in the mean time.
>> 
>> The RFC is silent on the matter.  The abort got added in 3.8 so
>> it's been there for a while.
> 
> I see, commit de4594a51c90 ("sctp: send abort chunk when max_retrans
> exceeded") added the behaviour.
> 
>>> Hmm, untested, but could you try something like that?
>>> 
>>> diff --git a/net/sctp/sm_sideeffect.c b/net/sctp/sm_sideeffect.c
>>> index fef2acd..5ce198d 100644
>>> --- a/net/sctp/sm_sideeffect.c
>>> +++ b/net/sctp/sm_sideeffect.c
>>> @@ -584,7 +584,8 @@ static void sctp_cmd_assoc_failed(sctp_cmd_seq_t *commands,
>>>          sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP,
>>>                  SCTP_ULPEVENT(event));
>>> 
>>> -    if (asoc->overall_error_count >= asoc->max_retrans) {
>>> +    if (asoc->overall_error_count >= asoc->max_retrans &&
>>> +        error != SCTP_ERROR_NO_ERROR) {
>>>          abort = sctp_make_violation_max_retrans(asoc, chunk);
>>>          if (abort)
>>>              sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> 
>> This would pretty much stop all ABORTs due to excessive rtx.  Might
>> as well take the code out :).
>> 
>> I was a bit concerned about this ABORT when it went in.
> 
> So effectively, if I understand the argument from the commit, the
> assumption is that the ABORT would never reach the peer anyway, but
> is a way for tcpdump users to see on the wire that rtx limit has
> been exceeded and since there's not mentioned anything in the RFC
> about this, it doesn't break it. Hm.
Yepp. It might not reach the peer or it might. If it does it helps
to keep the states in sync. If it doesn't it sometimes helps in
analysing tracefiles. In BSD, we also send it. It is not required,
doesn't harm and is useful in some cases...

Best regards
Michael
> 
> Sun Paul, what exactly broke in your scenario? Can you be more explicit?
> 
> Thanks,
> Daniel
> 

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/23/2015 07:36 PM, Michael Tuexen wrote:
...
> Yepp. It might not reach the peer or it might. If it does it helps
> to keep the states in sync. If it doesn't it sometimes helps in
> analysing tracefiles. In BSD, we also send it. It is not required,
> doesn't harm and is useful in some cases...

Ok, as the TCB is destroyed in any case, should be fine then.

Thanks,
Daniel

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/23/2015 07:36 PM, Michael Tuexen wrote:
...
> Yepp. It might not reach the peer or it might. If it does it helps
> to keep the states in sync. If it doesn't it sometimes helps in
> analysing tracefiles. In BSD, we also send it. It is not required,
> doesn't harm and is useful in some cases...

Ok, as the TCB is destroyed in any case, should be fine then.

Thanks,
Daniel

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

Hi

sorry for the late reply. I am a bit confused. when side-A sends a
request to side-B, and side-B return the response, but side-A keep
re-transmit the same request to side-B, why side-B needed to send a
ABORT to side-A?

If it is used in order to reestablish the connection, shoudn't it
should be side-A to send ABORT instead?

- PS

On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
> ...
>>
>> Yepp. It might not reach the peer or it might. If it does it helps
>> to keep the states in sync. If it doesn't it sometimes helps in
>> analysing tracefiles. In BSD, we also send it. It is not required,
>> doesn't harm and is useful in some cases...
>
>
> Ok, as the TCB is destroyed in any case, should be fine then.
>
> Thanks,
> Daniel

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

Hi

sorry for the late reply. I am a bit confused. when side-A sends a
request to side-B, and side-B return the response, but side-A keep
re-transmit the same request to side-B, why side-B needed to send a
ABORT to side-A?

If it is used in order to reestablish the connection, shoudn't it
should be side-A to send ABORT instead?

- PS

On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
> ...
>>
>> Yepp. It might not reach the peer or it might. If it does it helps
>> to keep the states in sync. If it doesn't it sometimes helps in
>> analysing tracefiles. In BSD, we also send it. It is not required,
>> doesn't harm and is useful in some cases...
>
>
> Ok, as the TCB is destroyed in any case, should be fine then.
>
> Thanks,
> Daniel

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Marcelo Ricardo Leitner]

Hi,

On 25-01-2015 23:27, Sun Paul wrote:
> Hi
>
> sorry for the late reply. I am a bit confused. when side-A sends a
> request to side-B, and side-B return the response, but side-A keep
> re-transmit the same request to side-B, why side-B needed to send a
> ABORT to side-A?

That happens on data transfers. When A pushes data to B, A has to retry it 
until B finally acknowledges it and A receive this signal. If the ack from B 
gets dropped, A has no way to know if a) the ack was lost or b) its initial 
message never actually made it to A, thus it retransmits. If it reaches a 
limit, it gives up..

> If it is used in order to reestablish the connection, shoudn't it
> should be side-A to send ABORT instead?

Meant to reestablish it? Not really.. just to keep both sides in sync, as A 
has given up by then.

   Marcelo

> - PS
>
> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>> ...
>>>
>>> Yepp. It might not reach the peer or it might. If it does it helps
>>> to keep the states in sync. If it doesn't it sometimes helps in
>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>> doesn't harm and is useful in some cases...
>>
>>
>> Ok, as the TCB is destroyed in any case, should be fine then.
>>
>> Thanks,
>> Daniel
> --
> 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
>

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Marcelo Ricardo Leitner]

Hi,

On 25-01-2015 23:27, Sun Paul wrote:
> Hi
>
> sorry for the late reply. I am a bit confused. when side-A sends a
> request to side-B, and side-B return the response, but side-A keep
> re-transmit the same request to side-B, why side-B needed to send a
> ABORT to side-A?

That happens on data transfers. When A pushes data to B, A has to retry it 
until B finally acknowledges it and A receive this signal. If the ack from B 
gets dropped, A has no way to know if a) the ack was lost or b) its initial 
message never actually made it to A, thus it retransmits. If it reaches a 
limit, it gives up..

> If it is used in order to reestablish the connection, shoudn't it
> should be side-A to send ABORT instead?

Meant to reestablish it? Not really.. just to keep both sides in sync, as A 
has given up by then.

   Marcelo

> - PS
>
> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>> ...
>>>
>>> Yepp. It might not reach the peer or it might. If it does it helps
>>> to keep the states in sync. If it doesn't it sometimes helps in
>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>> doesn't harm and is useful in some cases...
>>
>>
>> Ok, as the TCB is destroyed in any case, should be fine then.
>>
>> Thanks,
>> Daniel
> --
> 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
>

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

When an ABORT is sent to side-A, side-A INIT a new connection again.

On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
>> request to side-B, and side-B return the response, but side-A keep
>> re-transmit the same request to side-B, why side-B needed to send a
>> ABORT to side-A?
>
>
> That happens on data transfers. When A pushes data to B, A has to retry it
> until B finally acknowledges it and A receive this signal. If the ack from B
> gets dropped, A has no way to know if a) the ack was lost or b) its initial
> message never actually made it to A, thus it retransmits. If it reaches a
> limit, it gives up..
>
>> If it is used in order to reestablish the connection, shoudn't it
>> should be side-A to send ABORT instead?
>
>
> Meant to reestablish it? Not really.. just to keep both sides in sync, as A
> has given up by then.
>
>   Marcelo
>
>> - PS
>>
>> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>>> ...
>>>>
>>>>
>>>> Yepp. It might not reach the peer or it might. If it does it helps
>>>> to keep the states in sync. If it doesn't it sometimes helps in
>>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>>> doesn't harm and is useful in some cases...
>>>
>>>
>>>
>>> Ok, as the TCB is destroyed in any case, should be fine then.
>>>
>>> Thanks,
>>> Daniel
>>
>> --
>> 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
>>
>

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Sun Paul]

When an ABORT is sent to side-A, side-A INIT a new connection again.

On Mon, Jan 26, 2015 at 7:46 PM, Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> Hi,
>
> On 25-01-2015 23:27, Sun Paul wrote:
>>
>> Hi
>>
>> sorry for the late reply. I am a bit confused. when side-A sends a
>> request to side-B, and side-B return the response, but side-A keep
>> re-transmit the same request to side-B, why side-B needed to send a
>> ABORT to side-A?
>
>
> That happens on data transfers. When A pushes data to B, A has to retry it
> until B finally acknowledges it and A receive this signal. If the ack from B
> gets dropped, A has no way to know if a) the ack was lost or b) its initial
> message never actually made it to A, thus it retransmits. If it reaches a
> limit, it gives up..
>
>> If it is used in order to reestablish the connection, shoudn't it
>> should be side-A to send ABORT instead?
>
>
> Meant to reestablish it? Not really.. just to keep both sides in sync, as A
> has given up by then.
>
>   Marcelo
>
>> - PS
>>
>> On Sat, Jan 24, 2015 at 3:05 AM, Daniel Borkmann <dborkman@redhat.com>
>> wrote:
>>>
>>> On 01/23/2015 07:36 PM, Michael Tuexen wrote:
>>> ...
>>>>
>>>>
>>>> Yepp. It might not reach the peer or it might. If it does it helps
>>>> to keep the states in sync. If it doesn't it sometimes helps in
>>>> analysing tracefiles. In BSD, we also send it. It is not required,
>>>> doesn't harm and is useful in some cases...
>>>
>>>
>>>
>>> Ok, as the TCB is destroyed in any case, should be fine then.
>>>
>>> Thanks,
>>> Daniel
>>
>> --
>> 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
>>
>

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/26/2015 02:17 PM, Sun Paul wrote:
> When an ABORT is sent to side-A, side-A INIT a new connection again.

Even if the ABORT is not being sent, the peer (the one who would send
his ABORT) closes the TCB from his side silently then. Any messages that
would afterwards arrive on this dead connection would be answered with
an oob ABORT just as well. I'm still missing the bigger picture on your
use-case scenario here, I guess ... why is the recommended rtx limit not
sufficient?

Re: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Daniel Borkmann]

On 01/26/2015 02:17 PM, Sun Paul wrote:
> When an ABORT is sent to side-A, side-A INIT a new connection again.

Even if the ABORT is not being sent, the peer (the one who would send
his ABORT) closes the TCB from his side silently then. Any messages that
would afterwards arrive on this dead connection would be answered with
an oob ABORT just as well. I'm still missing the bigger picture on your
use-case scenario here, I guess ... why is the recommended rtx limit not
sufficient?

Re: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 05:25 AM, Sun Paul wrote:
> Hi
> 
> I would like to check the behave in LKSCTP.
> 
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> 
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
> 
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?
> 

Why do you not want ABORT to be sent? SCTP has attempted to retransmit
the data maximum allows times, and at this point it will terminate
the association.  It sends an ABORT notifying the peer of this, but
most likely the peer is unreachable anyway.

Any message that a peer sends at this point will most likely result
in an ABORT to be send back or an association restart.  Might
as well start fresh.

-vlad

> Thanks
> 
> PS
> --
> 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: Fwd: Question on SCTP ABORT chunk is generated when the association_max_retrans is reached

[Vlad Yasevich]

On 01/23/2015 05:25 AM, Sun Paul wrote:
> Hi
> 
> I would like to check the behave in LKSCTP.
> 
> we are running DIAMETER message over SCTP, and we have set the
> parameter "net.sctp.association_max_retrans = 4" in the LinuxOS.
> 
> We noticed that when remote peer have retry to send the same request
> for 4 times, the LKSCTP will initiate an ABORT chunk with reason
> "association exceeded its max_retrans count".
> 
> We would like to know whether this is the correct behavior? is there
> any other option that we can alter in order to avoid the ABORT chunk
> being sent?
> 

Why do you not want ABORT to be sent? SCTP has attempted to retransmit
the data maximum allows times, and at this point it will terminate
the association.  It sends an ABORT notifying the peer of this, but
most likely the peer is unreachable anyway.

Any message that a peer sends at this point will most likely result
in an ABORT to be send back or an association restart.  Might
as well start fresh.

-vlad

> Thanks
> 
> PS
> --
> 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
>