Sending is forced upon incoming NAK

[maxsharabayko]

When SRT receives a NAK report, it immediately (re-)schedules a sending event over an SRT socket, ignoring any pacing restrictions.
As a result of this rescheduling, only the first packet in the sender's loss list will be retransmitted immediately, the rest will follow pacing restrictions.
In case there is a lot of NAK reports arriving, pacing restrictions might be notably violated.

See this line in CUDT::processCtrlLossReport(..):

m_pSndQueue->m_pSndUList->update(this, CSndUList::DO_RESCHEDULE);

Versions

• SRT Versions: v1.4.2 and prior.

Related issue: #713.

Note: The same behavior was in UDT.

TODO

Investigate if it makes sense to force sending in case NAK report is received. Logically, if there is already a scheduled time for the next sending operation, it should be followed, even if it will be retransmission instead of sending of the next original packet.

[jeandube]

The UDT output pace was entirely controlled by the congestion control algorithm designed for readily available input data such as a file and variation was less critical than for live feed which SRT tries to address.

I think SRT output pace rate follows the setting better when there is a lost list because for a real time feed the normal output pace setting is the input stream rate plus an overhead for retransmission. The loss list acts as a file with available packets to transmit when the scheduled time to transmit (determined by output pacing) comes. while in absence of loss and an output-pace being input pace + overhead% there is often an empty sending buffer when the sending time comes. This is something I wanted to address before submitting the Output Pace Mode PR. Currently the overhead is applied all the time, with or without loss, with the naïve idea to take some advance in case of loss in the future but this does not work with a real time feed. One possible solution would be to apply the overhead to the output pace only in presence of loss. Overhead that could be proportional to the lost list size or loss rate.

Sorry to hijack this issue with these details not completely related to the question asked. To answer I think that retransmission of lost packets shall follow the output packing since it already accounts for lost.

[maxsharabayko]

Fixed in PR #2232