Question on SACK handling in LKSCTP

Question on SACK handling in LKSCTP

[Sun Paul]

Hi All

I would like to check how LKSCTP handle late arrival of SACK.

Our application is a DIAMETER based application running over SCTP, and
we found a strange behavior that if we send out DIAMETER request in a
batch, says 10 requests, the remote end point do not response at once,
and maybe after 5 secs, they response back with 10 SACKS.

If in this case, will the LKSCTP libraries wait for the SACK before
sending the new request? Or, it is actually controlled by user
application level?

Thanks

- RBK

Re: Question on SACK handling in LKSCTP

[Vlad Yasevich]

On 12/14/2015 08:13 PM, Sun Paul wrote:
> Hi All
> 
> I would like to check how LKSCTP handle late arrival of SACK.
> 
> Our application is a DIAMETER based application running over SCTP, and
> we found a strange behavior that if we send out DIAMETER request in a
> batch, says 10 requests, the remote end point do not response at once,
> and maybe after 5 secs, they response back with 10 SACKS.

The fact that you get 10 SACKs back means that you are transmitting
each DIAMETER request individually.  So while at the DIAMETER level you
may be batching, SCTP isn't bundling messages.

Your statement about getting sacks back after 5 seconds leads to me
believe that you have a very long rtt in your setup for some reason.
5 seconds is really excessive...

There could be multihoming issues or something else and without more
information it's hard to say.

> 
> If in this case, will the LKSCTP libraries wait for the SACK before
> sending the new request? Or, it is actually controlled by user
> application level?

The amount of data SCTP can have outstanding is governed by available
congestion window and receive window.  Once either of those windows
is full, SCTP will not transmit more data until the window opens again.
The windows will using open when a SACK arrives acknowledging that
data.

If a SACK isn't receiving within the round trip time, a retransmit is
triggered.  Late SACKs will not update the rtt, but will still open windows
for more data to be sent.

-vlad

> 
> Thanks
> 
> - RBK
> --
> 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 SACK handling in LKSCTP

[Sun Paul]

Thank Vald.

is it possible to let me know how I can identify the windows side from
packet trace? is it the a_rnwd?

- RBK

On Tue, Dec 15, 2015 at 11:38 AM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 12/14/2015 08:13 PM, Sun Paul wrote:
>> Hi All
>>
>> I would like to check how LKSCTP handle late arrival of SACK.
>>
>> Our application is a DIAMETER based application running over SCTP, and
>> we found a strange behavior that if we send out DIAMETER request in a
>> batch, says 10 requests, the remote end point do not response at once,
>> and maybe after 5 secs, they response back with 10 SACKS.
>
> The fact that you get 10 SACKs back means that you are transmitting
> each DIAMETER request individually.  So while at the DIAMETER level you
> may be batching, SCTP isn't bundling messages.
>
> Your statement about getting sacks back after 5 seconds leads to me
> believe that you have a very long rtt in your setup for some reason.
> 5 seconds is really excessive...
>
> There could be multihoming issues or something else and without more
> information it's hard to say.
>
>>
>> If in this case, will the LKSCTP libraries wait for the SACK before
>> sending the new request? Or, it is actually controlled by user
>> application level?
>
> The amount of data SCTP can have outstanding is governed by available
> congestion window and receive window.  Once either of those windows
> is full, SCTP will not transmit more data until the window opens again.
> The windows will using open when a SACK arrives acknowledging that
> data.
>
> If a SACK isn't receiving within the round trip time, a retransmit is
> triggered.  Late SACKs will not update the rtt, but will still open windows
> for more data to be sent.
>
> -vlad
>
>>
>> Thanks
>>
>> - RBK
>> --
>> 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 SACK handling in LKSCTP

[Vlad Yasevich]

On 12/14/2015 11:05 PM, Sun Paul wrote:
> Thank Vald.
> 
> is it possible to let me know how I can identify the windows side from
> packet trace? is it the a_rnwd?

That's is the announced receive window (how much buffer space the receiver
has available).

-vlad

> 
> - RBK
> 
> On Tue, Dec 15, 2015 at 11:38 AM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> On 12/14/2015 08:13 PM, Sun Paul wrote:
>>> Hi All
>>>
>>> I would like to check how LKSCTP handle late arrival of SACK.
>>>
>>> Our application is a DIAMETER based application running over SCTP, and
>>> we found a strange behavior that if we send out DIAMETER request in a
>>> batch, says 10 requests, the remote end point do not response at once,
>>> and maybe after 5 secs, they response back with 10 SACKS.
>>
>> The fact that you get 10 SACKs back means that you are transmitting
>> each DIAMETER request individually.  So while at the DIAMETER level you
>> may be batching, SCTP isn't bundling messages.
>>
>> Your statement about getting sacks back after 5 seconds leads to me
>> believe that you have a very long rtt in your setup for some reason.
>> 5 seconds is really excessive...
>>
>> There could be multihoming issues or something else and without more
>> information it's hard to say.
>>
>>>
>>> If in this case, will the LKSCTP libraries wait for the SACK before
>>> sending the new request? Or, it is actually controlled by user
>>> application level?
>>
>> The amount of data SCTP can have outstanding is governed by available
>> congestion window and receive window.  Once either of those windows
>> is full, SCTP will not transmit more data until the window opens again.
>> The windows will using open when a SACK arrives acknowledging that
>> data.
>>
>> If a SACK isn't receiving within the round trip time, a retransmit is
>> triggered.  Late SACKs will not update the rtt, but will still open windows
>> for more data to be sent.
>>
>> -vlad
>>
>>>
>>> Thanks
>>>
>>> - RBK
>>> --
>>> 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
>>>
>>