Drift Tracer: RTT samples are now taken into account when calculating the clock drift

[maxsharabayko]

RTT samples are now taken into account when calculating the clock drift.

Drift Estimation

TSBPD time base is the base time difference between the local clock of the receiver, and the clock used by the sender to timestamp packets being sent.
It is first initialized with the reception of the conclusion handshake as follows:

usTsbpdTimeBase = Tnow - usPktTimeStamp,

where Tnow is the time the HS packet is received (current time), usPktTimeStamp is the timestamp set on the packet.

For any further packet with its usPktTimeStamp corresponding to the sending time (only true for control packets), It is assumed that:

Tnow = usTsbpdTimeBase + usPktTimeStamp

Any consistent difference is caused by the drift of the two clocks (SND and RCV).

Therefore, drift is measured on every incoming ACKACK control packet as:

DriftSample = Tnow - (usTsbpdTimeBase + usPktTimeStamp).

However, the formula does not take possible network delay change into account. Longer or shorter journeys on the net result is a shift of the arrival time.

Taking RTT Sample into Account

RTT sample is measured on every ACK-ACKACK pair. Therefore, it is available at the time of drift sample estimation. RTT sample can be used to estimate the change in one-way network delay (SND->RCV) as:

usRTTDelta = usRTTSample - usRTT0,

where RTT0 is the first know RTT sample. Ideally, it should be estimated at the handshaking stage, but this is not yet implemented. The very first RTT measurement is taken instead with an assumption that it is close to the initial RTT.

Thus, usRTTDelta / 2 is assumed to roughly correspond to the change of the one-way network delay. This is of course close to the actual value for symmetric networks, but might be far from the truth for asymmetric networks. However, it is the best guess available.
So, this PR changes drift sample estimation to:

DriftSample = Tnow - (usTsbpdTimeBase + usPktTimeStamp) - usRTTDelta / 2.

Notes

Fixes #753, #984.
Refactoring extracted to PR #1968. TSBPD and clock drift tracing logic are moved to a separate class CTsbpdTime. It should also provide a cleaner update of #1964.

TODO

• Split PR into two commits: 1) refactoring (CTsbpdTime), 2) RTT usage in Drift.
• Provide description of changes.
• Provide test results.

[maxsharabayko]

Without RTT Adjustment (SRT v1.4.3 and prior)

Experiment set up

• SRTO_RCVLATENCY: 1000 s.
• Artificial network delay value (1/2 RTT):
  • 0-20s: 25 ms (RTT 50 ms);
  • 20-50s: 250 ms (RTT 500 ms);
  • 50-60s: 25 ms (RTT 50 ms);

Results

Changing RTT changes end-to-end latency (roughly +225ms).
The receiver buffer fullness stays almost the same, although packets start arriving 225 ms later. Expected behavior: decrease in receiver buffer fullness by 125 ms.

[maxsharabayko]

With RTT Adjustments (SRT v1.4.4)

Experiment set up

• SRTO_RCVLATENCY: 1000 s.
• Artificial network delay value (1/2 RTT):
  • 0-20s: 25 ms (RTT 50 ms);
  • 20-50s: 250 ms (RTT 500 ms);
  • 50-60s: 25 ms (RTT 50 ms);

Results

Changing RTT does not change end-to-end latency.
The receiver buffer fullness is adjusted (-225 ms) to bear with the increased network delay. 👍

[gou4shi1]

So after this patch, drift tracer will only reflect the change of clock drift, will not be affected by network latency?
But if both my sender and receiver use steady clock, drift tracer become useless?

[maxsharabayko]

Two steady clocks also drift. The drift, in this case, will be monotonic by nature: an increasing or decreasing trend.
When one of the parties uses a system clock, the drift will vary over time. For example, increasing until the next NTP update, then going down, then increasing again, and so on.

Therefore, the drift tracer is needed in any case.

[gou4shi1]

Got it, but the initial tsbpdTimeBase=diff_between_two_time_reference + network_latency (correct me if I'm wrong), what if the network latency changed, how to update the tsbpdTimeBase with the new drift tracer?

[maxsharabayko]

@gou4shi1 If network latency changes, we assume this change is reflected in the change of RTT, and compensate it.
RTT/2 is the best estimation of one-way delay in symmetric networks.
Please see SRT Cookbook page on latency, and PR description for more details.

[gou4shi1]

For example, the initial tsbpdTimeBase is 100 (clock diff) + 50 (network latency), so the time-to-play is delayed by 50 (network latency from timebase) + 120 (latency from config)
After a while, the network is better, network latency become 20, time-to-play will still be delayed by 170ms?

[gou4shi1]

For example, the initial tsbpdTimeBase is 100 (clock diff) + 50 (network latency), so the time-to-play is delayed by 50 (network latency from timebase) + 120 (latency from config) After a while, the network is better, network latency become 20, time-to-play will still be delayed by 170ms?

Actually my question is:
If the initial network is very bad, the initial one-way-delay RTT0/2 is very big, and it is included in tsbpdTimeBase, if the network becomes much better later, the initial one-way-delay is still keep in tsbpdTimeBase.

[maxsharabayko]

The end-to-end latency is formed once the handshake is made (CONCLUSION phase) as:
RTT0/2 + SRTO_RCVLATENCY.
After that SRT tries to keep it the same even if RTT falls or raises. That is one of the main goals of SRT in the live streaming configuration: once the end-to-end latency is set, preserve it while the connection is alive.

There is an idea for a feature request to add a possibility for a user to specify the desired target end-to-end latency. That would require SRT to determine RTT based on the Handshake exchange delays, and extract it from the buffering delay.
But that's not on the TODO list at the moment.

There is also another FR #2016 to add a possibility for a user to have an estimate of the actual end-to-end latency.

[gou4shi1]

Got it, thanks for your explanation :)