Subject: Some late comments on draft-ietf-quic-load-balancers

From: Watson Ladd <[email-masked]>
Date: Thu, 11 Mar 2021 14:48:05 -0800

Dear QUIC WG,

First a moment of unforgivable pedantry. Universal time is
unfortunately not the right name for UTC, which is slightly different.
It could also mean UT1 or some other variations  It's also not clear
what the future of computer timekeeping is and I know several places
don't synchronize to UTC internally. I think the best way to handle
this is to say something like "synchronized" and leave open as to
exactly how that is done.

I agree with the comments that there are too many options and should
be fewer. Other then that I didn't see any problems but I'm probably
too sleepy right now to spot them.

Sincerely,
Watson Ladd
-- 
Astra mortemque praestare gradatim

---

From: James <[email-masked]>
Date: Fri, 12 Mar 2021 14:19:02 +0100

I've raised a small PR[1] which should cover this, however I think there 
is some other considerations that may belong in a separate PR:

* What happens when a service receives a token with a timestamp which 
points to a time in the future? Should this just be accepted, or treated 
as an error?

* Is there a way we can remove the requirement for having time_t as the 
timestamp value and instead use a linear incrementing value relative to 
the server and service that is independent of other timescales?

- J

1: https://github.com/quicwg/load-balancers/pull/100

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 12 Mar 2021 19:08:57 +0100

Just to add some background.

UTC is Universal Time Coordinated. Universal Time is more genereal.

Disregarding timezones, we have UTC as a single point of reference. Predictably there is an adjustment every fourth year, except every 100th year, unless it is every 400th year. Also an adjustment is needed about every 4000 years or so, but that is not part of UTC so far.

The problem is that this is not enough because earth wobbles unpredictably. So we have unpredictable leap seconds that are added or subtracted or left unchanged at predictable intervals based on short term observations. Leap seconds are relevant in some areas because the earth can move a fair bit in one second. This is where UT1 time comes in as one of several ways to accommodate the imprecision  of UTC.

Most computer systems opt to define time as a monotonically increasing offset in seconds and fractions of seconds since midnight, January 1st, 1970 as observed from Greenwich, London. This is also known as Unix Time. Unix Time maps cleanly to UTC time to the extent that Unix Time can be seen as a UTC representation. This avoids any abrupt jumps in time, or slowly accelerated time up to leap second changes. UT1 cannot be mapped cleanly from Unix Time because it needs an earth wobble table to perform the translation, and that table needs to be kept up to date (literally).

However, even accounting for earths wobbling is not enough if you want to be really exact. In this case you cannot really tell the order of events any more:
https://www.quantamagazine.org/quantum-mischief-rewrites-the-laws-of-cause-and-effect-20210311/ <https://www.quantamagazine.org/quantum-mischief-rewrites-the-laws-of-cause-and-effect-20210311/>

Trivia: the Romans made the (to my knowledge) first recorded fence post error around year 1 by introducing leap years every 3 years instead of every 4 years. After about 30 years the error became apparent and was fixed.

Mikkel

> On 11 Mar 2021, at 23.48, Watson Ladd <[email-masked]> wrote:
> 
> Dear QUIC WG,
>

---

From: Martin Duke <[email-masked]>
Date: Fri, 12 Mar 2021 14:30:37 -0800

Thanks for the correction, and the PR. We can iterate on that to fix the
problem.

Regarding the bigger issue, yes, everyone agrees there are too many
options. The problem is there are lots of use cases and tradeoffs here. I
can unilaterally start cutting stuff out but I don't have any more insight
into what's most valuable than anyone else. This is where implementations
would be useful: facts on the ground would tell me what people really find
useful.

Martin

On Fri, Mar 12, 2021 at 10:09 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> Disregarding timezones, we have UTC as a single point of reference.
> Predictably there is an adjustment every fourth year, except every 100th
> year, unless it is every 400th year. Also an adjustment is needed about
> every 4000 years or so, but that is not part of UTC so far.
>
> The problem is that this is not enough because earth wobbles
> unpredictably. So we have unpredictable leap seconds that are added or
> subtracted or left unchanged at predictable intervals based on short term
> observations. Leap seconds are relevant in some areas because the earth can
> move a fair bit in one second. This is where UT1 time comes in as one of
> several ways to accommodate the imprecision  of UTC.
>
> Most computer systems opt to define time as a monotonically increasing
> offset in seconds and fractions of seconds since midnight, January 1st,
> 1970 as observed from Greenwich, London. This is also known as Unix Time.
> Unix Time maps cleanly to UTC time to the extent that Unix Time can be seen
> as a UTC representation. This avoids any abrupt jumps in time, or slowly
> accelerated time up to leap second changes. UT1 cannot be mapped cleanly
> from Unix Time because it needs an earth wobble table to perform the
> translation, and that table needs to be kept up to date (literally).
>
> However, even accounting for earths wobbling is not enough if you want to
> be really exact. In this case you cannot really tell the order of events
> any more:
>
> https://www.quantamagazine.org/quantum-mischief-rewrites-the-laws-of-cause-and-effect-20210311/
>
> Trivia: the Romans made the (to my knowledge) first recorded fence post
> error around year 1 by introducing leap years every 3 years instead of
> every 4 years. After about 30 years the error became apparent and was fixed.
>
> Mikkel
>