Re: Draft time stamps for Quic

[Tal Mizrahi <[e-mail]>]

Hi Christian,

Thanks for putting this draft together.

Two aspects that may be worth a bit more consideration:
- One-way-delay measurement requires the endpoints to be synchronized.
Since the epoch that was chosen in this draft is the beginning of the
connection, endpoints need to be synchronized about the beginning time
of the connection. The draft suggests to synchronize the beginning of
the connection by measuring the "phase_shift" value. Using
"latest_rtt/2" for the phase_shift calculation seems to assume that
the delay is symmetric. I agree with Watson's comment about symmetry -
if the path is asymmetric all the measurements will be biased.
- "We understand that clocks may drift over time, and that simply
estimating a phase shift at the beginning of a connection may be too
simplistic" - this is an important issue. It is not uncommon for PC
clocks to drift by 1 millisecond (or more) per minute. Accurate
measurement will probably require a more accurate synchronization
mechanism.

Cheers,
Tal.

On Wed, Feb 26, 2020 at 7:19 AM Watson Ladd <[e-mail]> wrote:
>
> So I was under the impression that one cannot determine whether
> asymmetric delay or clock skew is the problem between two machines.
> There are as many variables as unknowns. At best you can determine if
> the one way delay is changing on a leg. Having spent a good part of
> the last month on a project that would be much simpler if that wasn't
> case I'd be happy to know I was wrong.
>
> Sincerely,
> Watson
>