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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
