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
2021-11-03 14:59:46 +00:00
2022-02-16 12:37:35 +00:00
2022-04-27 10:09:21 +00:00
2021-01-20 15:01:07 +00:00
2022-02-20 14:22:13 +00:00
2021-12-08 08:53:00 +00:00
2020-07-13 11:42:07 +00:00
2021-08-23 13:37:55 +00:00
2021-12-16 17:45:31 +00:00

WebRTC is a free, open software project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. The WebRTC components have been optimized to best serve this purpose.

Our mission: To enable rich, high-quality RTC applications to be developed for the browser, mobile platforms, and IoT devices, and allow them all to communicate via a common set of protocols.

The WebRTC initiative is a project supported by Google, Mozilla and Opera, amongst others.

Development

See here for instructions on how to get started developing with the native code.

Authoritative list of directories that contain the native API header files.

More info

Description
No description provided
Readme 255 MiB
Languages
C++ 88.6%
C 3.3%
Java 3%
Objective-C++ 1.9%
Python 1.9%
Other 1%