Victor Boivie 01a0db2e74 dcsctp: Don't re-nack a fragment until sent again ... This is mainly an issue when sending items with partial reliability, with high bandwidth on a link with packet loss. In SCTP, when a fragment isn't included in the SACK a number of times, it's scheduled to be retransmitted or abandoned, if it has been retransmitted too many times already (depending configuration). Before this CL, if a fragment was NACKed and scheduled for retransmission, but couldn't be retransmitted immediately (due to congestion window not allowing it), future received SACKs - that would still indicate that the fragment hasn't been received yet - would still increment the retransmission counter. Which wasn't fair, because this fragment hasn't had a chance to be retransmitted yet. With this CL, the fragment will only have its retransmission counter increased when it is not already scheduled to be retransmitted, but actually sent on the wire and considered in-flight again. Bug: webrtc:12943 Change-Id: I2af08255650221c044cc14591a5835c885e94c58 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/259825 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Cr-Commit-Position: refs/heads/main@{#36683}		2022-04-28 08:28:33 +00:00
..
dcsctp	dcsctp: Don't re-nack a fragment until sent again	2022-04-28 08:28:33 +00:00