[core] Improved RTT estimation

[mbakholdina]

Improvements Done

Improved RTT estimation in the following way:

• On the receiver side, reset smoothed RTT to the very first RTT sample obtained from the ACK/ACKACK pair. At the beginning of a transmission, the value of smoothed RTT is either equal to INITIAL_RTT = 100 ms, or is taken from cache. It remains so until the very first ACKACK packet is received from the sender and triggers RTT sample calculation. At this moment, the smoothed RTT is reset to the very first RTT sample and the EWMA is applied further on the subsequent RTT samples.
• On the sender side, in the case of unidirectional transmission, the values of smoothed RTT and RTT variance are now extracted from the ACK packets. There is no more EWMA applied on the sender side to avoid double smoothing, see issue m_iRTT and m_iRTTVar double EWMA #782.
  The initial values of RTT and RTT variance are either equal to INITIAL_RTT = 100 ms and INITIAL_RTTVAR = 50 ms, or taken from sender's cache. Upon ACK packet reception, they can be reset to the receiver's RTT and RTTVar extracted from the ACK if those values are taken from the receiver's cache. Initial values of 100 ms and 50 ms will be ignored. Receiver's cache is of a higher priority meaning that in case of both peers have cache, receiver's cache wins.
• On the sender side, in the case of bidirectional transmission, the double smoothing is still applied to be consistent with the previous behaviour. Additionally, initial RTT values of 100 ms are not taken into account when calculating smoothed average. In general, the case of bidirectional transmission requires further improvements and testing as more complicated use case. Currently, it's out of scope.
• The RTT trace log has been added to test the changes appropriately. Use -DENFORCE_SRT_DEBUG_RTT=1 with cmake to activate it.

Fixes #782, #1769, #1818.

Test Cases

The tests were performed with the help of srt-xtransmit application with the following test parameters:

sendrate = 10 Mbps, RTT = 500 ms, latency = 2000 ms (4RTT), rcvbuf = 5625000 bytes

(see test case 6 from #1937).

The SRT library was built with the advanced RTT log plus the usage of monotonic clocks:

cmake -DENFORCE_SRT_DEBUG_RTT=1 -DENABLE_STDCXX_SYNC=ON ../
cmake —build ./

Test Case 1. Unidirectional transmission. Initial values for smoothed RTT and RTTVar are applied on both sides.

_build_rtt/bin/srt-xtransmit receive "srt://:4200?latency=2000&rcvbuf=5625000" --enable-metrics --metricsfile metrics-rcv.csv --metricsfreq 100ms --statsfile stats-rcv.csv --statsfreq 100ms -v

_build_rtt/bin/srt-xtransmit generate srt://192.168.2.2:4200?latency=2000 --sendrate 10Mbps --duration 120s --enable-metrics --statsfile stats-snd.csv --statsfreq 100ms -v

Test Case 2. Unidirectional transmission, resumed connection. Initial value for smoothed RTT is taken from cache.

2.1. Sender-caller, receiver-listener, reconnection on the receiver side. The cache is available on the receiver side only.

_build_rtt/bin/srt-xtransmit receive "srt://:4200?latency=2000&rcvbuf=5625000" --enable-metrics --metricsfile metrics-rcv.csv --metricsfreq 100ms --statsfile stats-rcv.csv --statsfreq 100ms --reconnect --handle-sigint -v

_build_rtt/bin/srt-xtransmit generate srt://192.168.2.2:4200?latency=2000 --sendrate 10Mbps --duration 20s --enable-metrics --statsfile stats-snd.csv --statsfreq 100ms --handle-sigint -v

The logic of applying the values from cache works correct, however, during this test, I've faced the following bug #1958.

The sender application has been restarted 4 times. As we can see from the first picture, for the first restart (see row 1859), the values of smoothed RTT and RTTVar are equal to the initial values of 100 ms and 50 ms, because the values from cache are not yet available. The socket is in process of closing, however it's not yet closed when the reconnection happens.

As can be seen from the following pictures, when the second reconnection happens (see row 3717), the value from cache is available (500288), however this value isn't correct and actually taken from the very first session.

2.2. Sender-listener, receiver-caller, reconnection on the sender side. The cache is available on the sender side only.

_build_rtt/bin/srt-xtransmit generate srt://:4200?latency=2000 --sendrate 10Mbps --duration 30s --enable-metrics --statsfile stats-snd.csv --statsfreq 100ms --reconnect --handle-sigint -v

_build_rtt/bin/srt-xtransmit receive "srt://192.168.2.1:4200?latency=2000&rcvbuf=5625000" --enable-metrics --metricsfile metrics-rcv.csv --metricsfreq 100ms --statsfile stats-rcv.csv --statsfreq 100ms --handle-sigint -v

Haven't faced the bug #1958 as in test case 2.1.

2.3. Reconnection on both sides, the cache is available on both sides.

_build_rtt/bin/srt-xtransmit receive "srt://:4200?latency=2000&rcvbuf=5625000" --enable-metrics --metricsfile metrics-rcv.csv --metricsfreq 100ms --statsfile stats-rcv.csv --statsfreq 100ms --reconnect --handle-sigint -v

_build_rtt/bin/srt-xtransmit generate srt://192.168.2.2:4200?latency=2000 --sendrate 10Mbps --duration 20s --enable-metrics --statsfile stats-snd.csv --statsfreq 100ms --reconnect --handle-sigint -v

• Haven't been tested as this functionality is not available in srt-xtransmit application.

Test Case 3. Bidirectional transmission.

develop/generate-null-receiver branch of srt-xtransmit was used to test the case of bidirectional transmission.

_build_rtt/bin/srt-xtransmit generate "srt://:4200?latency=2000&rcvbuf=5625000" --sendrate 1Mbps --duration 30s --statsfile generator-flop.csv --statsfreq 100ms -v

_build_rtt/bin/srt-xtransmit generate srt://192.168.2.2:4200?latency=2000 --sendrate 1Mbps --duration 30s --statsfile generator-flip.csv --statsfreq 100ms -v

The very first implementation showed that there was a variation in smoothed RTT and RTTVar at the beginning of a transmission. The screenshot below was taken on the caller side. In case of bidirectional transmission, at each peer we receive both ACK and ACKACK packets. The very first packet triggers the reset of smoothed RTT, however later there is still a chance to receive ACK packets with initial RTT value of 100 ms which will be taken into account while calculating smoothed average.

In the improved version, these values are simply ignored.

[maxsharabayko]

Minor corrections.