The Retransmission Queue contain all message fragments (DATA chunks)
that have once been sent, but not yet ACKed by the receiver. It will
process incoming SACK chunks, which informs it which chunks that the
receiver has seen (ACKed) and which that are lost (NACKed), and will
retransmit chunks when it's time.
If a message has been sent with partial reliability, e.g. to have a
limited number of retransmissions or a limited lifetime, the
Retransmission Queue may discard a partially sent and expired message
and will instruct the receiver that "don't expect this message - it's
expired" by sending a FORWARD-TSN chunk.
This currently also includes the congestion control algorithm as it's
tightly coupled with the state of the retransmission queue. This is
a fairly complicated piece of logic which decides how much data that
can be in-flight, depending on the available bandwidth. This is not done
by any bandwidth estimation, but similar to TCP, where data is sent
until it's lost, and then "we dial down a knob" and take it more
carefully from here on.
Future refactoring will try to separate the logic regarding fragment
retransmission and the congestion control algorithm.
Bug: webrtc:12614
Change-Id: I8678250abb766e567c3450634686919936ea077b
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/214046
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Reviewed-by: Harald Alvestrand <hta@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33833}
03e912abaf