Yeah that could be the reason. If you look for example at the test script https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/ordered/ordered-packet-loss-5.pkt there are two bundled SACK-Chunks sent by the linux kernel. this is not invalid behaviour but it is inefficien (line 78)t: +0.0 > sctp: SACK[flgs=0, cum_tsn=2, a_rwnd=..., gaps=[2:2, 4:4], dups=[]]; SACK[flgs=0, cum_tsn=4, a_rwnd=..., gaps=[2:2], dups=[]] The second SACK-Chunk has a higher cum_tsn and it would be more efficient to only send one SACK-Chunk in these cases. The FreeBSD implementation only sends the following SACK-Chunk in this case: +0.0 > sctp: SACK[flgs=0, cum_tsn=4, a_rwnd=..., gaps=[2:2], dups=[]] 2017-01-17 20:07 GMT+01:00 Xin Long <lucien.xin@xxxxxxxxx>: > On Tue, Jan 17, 2017 at 9:08 PM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: >> WWhenever receiving packets containing FORWARD-TSN chunks bundled with a >> DATA-Chunk the linux kernel sends currently two SACK-Chunks. >> This is suboptimal, because after processing both received chunks, it >> could send one SACK-Chunk. >> >> Testscripts available at: >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/ordered/ordered-packet-loss-5.pkt >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/ordered/ordered-packet-loss-12.pkt >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/ordered/ordered-packet-loss-13.pkt >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-2.pkt >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-5.pkt >> - https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-12.pkt >> > you test script may triggered this: > > /* From 12.2 Parameters necessary per association (i.e. the TCB): > * > * Ack State : This flag indicates if the next received packet > * : is to be responded to with a SACK. ... > * : When DATA chunks are out of order, SACK's > * : are not delayed (see Section 6). > * > * [This is actually not mentioned in Section 6, but we > * implement it here anyway. --piggy] > */ > if (max_tsn_seen != ctsn) > asoc->peer.sack_needed = 1; > > if max_tsn_seen(the highest TSN we've seen) != ctsn(Cumulative TSN ACK Point), > the sack will send immediately. :) -- 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
