Backup groups: Take source rate estimate from an active link on idle member activation

[maxsharabayko]

In the source (input) rate estimation configuration (SRTO_MAXBW=0, SRTO_INPUTBW=0) SRT estimates input rate based on the data coming from the app via srt_sendmsg2(..). The estimate is used to set the maximum BW limit and pacing rate of sending.
In the main/backup mode an inactive member does not get any data for sending and does not perform any rate estimation.
Once it is activated, the rate estimator state is taken from an active member and assigned to this newly activated member.

⚠️ An activated member would instantly get all unacknowledged packets from the active member. However, those packets already have source timestamps. The source rate estimation honors these timestamps, but uses it only to estimate the interval. The estimate would then be overestimated a bit.

Fixes #2122, fixes #2200.

[maxsharabayko]

Before the PR

Switching to this member socket from another one. The black line denoted the maximum bandwidth limit applied. No line means unlimited (i.e. 1 Gbps).
It can be seen that during the switch there was no limit applied, therefore the spike of sending rate went above the configured 25% retransmission overhead on top of the source bitrate.

The PR

The maximum bandwidth limit of 1.29068 Mbps is applied right at the moment the member socket is activated.
It is then recalculated to 1.39937 Mbps as unacknowledged packets from the main link are being submitted to the socket.

Test

srt-xtransmit generate --sendrate 1Mbps "srt://127.0.0.1:4200?maxbw=0&grouptype=backup&weight=1" \
      srt://127.0.0.1:4201 --statsfile group-snd.csv --statsfreq 100ms -v --duration 20s

srt-xtransmit receive srt://:4200 srt://:4201 --statsfile group-rcv.csv --statsfreq 100ms -v

[maxsharabayko]

The increased BW limit is because the rate estimation calculates how many bytes are submitted within a certain period, even though relying on the source time of packets.

void CRateEstimator::updateInputRate(const time_point& time, int pkts, int bytes)
{
    // no input rate calculation
    if (m_InRatePeriod == 0)
        return;

    if (is_zero(m_tsInRateStartTime))
    {
        m_tsInRateStartTime = time;
        return;
    }

    m_iInRatePktsCount  += pkts;
    m_iInRateBytesCount += bytes;

    // Trigger early update in fast start mode
    const bool early_update = (m_InRatePeriod < INPUTRATE_RUNNING_US) && (m_iInRatePktsCount > INPUTRATE_MAX_PACKETS);

    const uint64_t period_us = count_microseconds(time - m_tsInRateStartTime);
    if (early_update || period_us > m_InRatePeriod)
    {
        // Required Byte/sec rate (payload + headers)
        m_iInRateBytesCount += (m_iInRatePktsCount * CPacket::SRT_DATA_HDR_SIZE);
        m_iInRateBps = (int)(((int64_t)m_iInRateBytesCount * 1000000) / period_us);
        LOGC(bslog.Warn,
              log << "updateInputRate: pkts:" << m_iInRateBytesCount << " bytes:" << m_iInRatePktsCount
                  << " rate=" << (m_iInRateBps * 8) / 1000 << "kbps interval=" << period_us);
        m_iInRatePktsCount  = 0;
        m_iInRateBytesCount = 0;
        m_tsInRateStartTime = time;

        setInputRateSmpPeriod(INPUTRATE_RUNNING_US);
    }
}

[maxsharabayko]

A simple solution would be to ignore samples with timestamps from the past. The estimate then looks better, but there is some overhead anyway, just happens a bit later.

--- a/srtcore/buffer.cpp
+++ b/srtcore/buffer.cpp
@@ -133,6 +133,11 @@ void CRateEstimator::updateInputRate(const time_point& time, int pkts, int bytes
         m_tsInRateStartTime = time;
         return;
     }
+    else if (time < m_tsInRateStartTime)
+    {
+        // Old packets are being submitted for estimation, e.g. during the backup link activation.
+        return;
+    }

     m_iInRatePktsCount  += pkts;
     m_iInRateBytesCount += bytes;