[AVTCORE] Abs Capture Timestamps - measurements

[Harald Alvestrand <[e-mail]>]

As part of the prepwork for the abs-capture-timestamp draft, we have 
done some measurements on the usage of the extension in practical 
environments.

The data below is based on a few days of data captured on Chrome canary, 
so may be suggestive, but not definitive. We also cannot rule out 
measurement error.

The common usages seems to be:

- Direct source-destniation connection: Extension arrives in the first 
packet, offset is zero.
- Transmissions via one or more relay hops where offset estimation is 
being performed at the relay. Typically this is a multiway conference; 
the measuring system may join the conference before or after the sending 
system has joined.

We measure the following numbers:
- Time from first RTP packet to first packet with extension (ExtensionWait)
- Time from first RTP packet to first packet with an extension that 
includes offset (OffsetWait)
- Difference between the timestamp and the local clock (Delta)
- The value of the offset (Offset)
- The variation in those two values between successive extensions 
(DeltaDeviation, OffsetDeviation)

Significant measures, from a day of measurement on Canary:

- 70% of the data had ExtensionWait of zero. This means that the 
extension arrived on the first RTP packet.
- 6% of the data has a Delta of zero. If this is not a measurement 
error, it is likely to be loopback connections.
- Delta for non-zero measurements clustered around 400 msec.
- The average DeltaDeviation is around 6 milliseconds. This indicates 
some noise.
- 67% of the data had OffsetWait of zero. Again, indicating that the 
offset was already present in the first packet. This can happen if the 
RTT of the source to the estimating relay is already computed before the 
receiver joins.
- The Offset values showed 3% zeroes.
Zero likely means point-to-point calls; originator will send offset zero 
when its capture clock and NTP timestamp clocks are in sync.
- The rest of the Offset values clustered loosely around half a second, 
with very few values below 10 ms or above 4 seconds. There were, 
however, outliers beyond 15 minutes (the top of the histogram), 
indicating clocks strongly desynchronized.
- Offset deviation was low, mostly zeroes, with 99% below one 
millisecond.. This indicates that once RTT estimates are done, the 
offset values are relatively stable (but not constant).