Re: Some late comments on draft-ietf-quic-load-balancers
Martin Duke <martin.h.duke@gmail.com> Fri, 12 March 2021 22:30 UTC
Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F26F3A16E8 for <quic@ietfa.amsl.com>; Fri, 12 Mar 2021 14:30:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYxbPtz--xhj for <quic@ietfa.amsl.com>; Fri, 12 Mar 2021 14:30:48 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393323A16E7 for <quic@ietf.org>; Fri, 12 Mar 2021 14:30:48 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id o9so27421092iow.6 for <quic@ietf.org>; Fri, 12 Mar 2021 14:30:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oIp+8rlpIEHm5bVDBKIXRIiJIKzEZIPqT+HE4HaIiww=; b=jsR5AkgQp54UUu/ft+A2Y/mjA84MBBmQNppICkddQwZBvzH3tY+Tgo1V3MPOP53YGb 4VctPSPDIvhxHH67TKdM1h30QVghBv8VuNf4W1HggYpMZo9DsyD3HlaX3/jibQg1GUWF /oxEC2aPXA5MlkvDtepikJMTxj2sqY/2JRSCabwjAbVNVSCik0YRCPVM/QyXZft/V3o+ xJmBZ5iyzCsd+dhodyVYZe/MRHL0PNEmwzbQhvkyAJ8EApvpb7AGIMK94aWIj4GEK/NQ 74Xb0e7H5wgIJ2lNlCy6vfLZruFbqMRSMMEVgelE5Qn9z+AVb49FPt62+MUWhORism6h KJ7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oIp+8rlpIEHm5bVDBKIXRIiJIKzEZIPqT+HE4HaIiww=; b=lq45E+l4XvcD+bij37FEZSLrIKpiCMHpgWghUkX84Mx4MC5yR+QnrH9S78eNezfk8E uQyXCjCF28G9t5gxWS5ScmfRAkYMvQE4sykXYJvr602wBfEzmDQEgjZJPbVm4nkMTBBj v03iOO6qXlHLgpLi+I48xCJ1q0s89FwSY/cQoZkAGAO+pHLW37JrRnUlz6GkrjElU4sm c7QjOfiPGVTqr8pQIRYsT6bKqsbKfC0Pm73mNlF0xsqw3QjV6j46g/6ChxFdEJSYfVvC RtHFKZP7BkDgRt0euyPfH5z6uqoED623FRFDEShrRNk5Z8hRUaEKL3TbI7ZwYkwrPaUk XoYw==
X-Gm-Message-State: AOAM530/meR0VwxNeH5ZARzBUr7tzoySVwiAvC2vaoxtZFVGuSQBHYJZ xmy8uVPas8j7pNoxXHU8qP57jwq7wGIxcx0rciw=
X-Google-Smtp-Source: ABdhPJzq7wReb2cXVtPi6cpPASxTwKxbXVhHbWZKDUTdjOHmx8v9FO5vEFb9W9k+fPHWkG3MO/4hDDAdxjjQyO97BwI=
X-Received: by 2002:a05:6638:d4e:: with SMTP id d14mr1357638jak.103.1615588246785; Fri, 12 Mar 2021 14:30:46 -0800 (PST)
MIME-Version: 1.0
References: <CACsn0cn70MK699XyWmYp7i3nw7TSwPS4q94A4BFf4FFVy9MNrg@mail.gmail.com> <1B7BEBA6-FF98-45AD-A5AB-F9EE702359C6@gmail.com>
In-Reply-To: <1B7BEBA6-FF98-45AD-A5AB-F9EE702359C6@gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Fri, 12 Mar 2021 14:30:37 -0800
Message-ID: <CAM4esxS12KUYWAjfoXqUBZ-4Ua7fLTCd_6AoJ_Y4ViwiZDPwtg@mail.gmail.com>
Subject: Re: Some late comments on draft-ietf-quic-load-balancers
To: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Cc: Watson Ladd <watsonbladd@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008d930605bd5e7311"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/q_oP2Q5FdUqc6QYwLFPoh9DeIPY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Mar 2021 22:30:50 -0000
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 <mikkelfj@gmail.com> wrote: > 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/ > > 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 <watsonbladd@gmail.com> wrote: > > 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 > > >
- Some late comments on draft-ietf-quic-load-balanc… Watson Ladd
- Re: Some late comments on draft-ietf-quic-load-ba… James
- Re: Some late comments on draft-ietf-quic-load-ba… Mikkel Fahnøe Jørgensen
- Re: Some late comments on draft-ietf-quic-load-ba… Martin Duke