Re: [Ntp] NTPv5 draft suggestion to move timescale offset into extension fields.

David Venhoek <david@venhoek.nl> Mon, 07 November 2022 14:29 UTC

Return-Path: <david@venhoek.nl>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5762FC1522D1 for <ntp@ietfa.amsl.com>; Mon, 7 Nov 2022 06:29:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venhoek-nl.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BiB3I0dG1JMP for <ntp@ietfa.amsl.com>; Mon, 7 Nov 2022 06:29:11 -0800 (PST)
Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F289C1522C9 for <ntp@ietf.org>; Mon, 7 Nov 2022 06:29:10 -0800 (PST)
Received: by mail-ej1-x62b.google.com with SMTP id n12so30513075eja.11 for <ntp@ietf.org>; Mon, 07 Nov 2022 06:29:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venhoek-nl.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=xi6fEWQomaZyPtXIjiL66IJqBJiw9qCywyhnABhRNFY=; b=xVOo1NZh8TTXxMVe1+KSedBNiaFG6tiBOaLUMFHhxqEaQPom5If19cPFZ8vycATm8E ufbqx3P+uknul3BO4Sj8bAH5T2G39D2nVhRi1z7x+Sb6eYc3bD/F1WVZm8nc+SO+27CQ ZbpoiO81vS/js+CIaOaCPcds3UU1Joh+eORE12ubX1XsQdsagP2mTBSTzh21L1D2u57K oDS8Db6/VpZ45QXcLSrpQv22sutj1KB/TBqSiyTmSZOxMnvPwHSlpxxAw7ztuiK2bdLw rDUlTS3WjZvY3Erdo7pL5PaXdwYqpXhjkcYlNQznsu1z4r7VktQdHdK1PyoRX7mec+Gz i4dg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=xi6fEWQomaZyPtXIjiL66IJqBJiw9qCywyhnABhRNFY=; b=jqnApk9v2F26Ivj2CL2L7rqzKTALZ6nz2UtQ7DyzADWDEYoEd1Vk7mve4wG1HKBSN6 8A35wAi+fbj9ckxG6netduG20QYlQ4UBhyGOqPBmdZNEIW8PIH1Jd+Tm6m1hSnPbn/4K i5y8RBMtIBVeg13r4CAkgffqBzQzS8gMSTtoknn4jc4zHWz5zolFwn8jfPg13RrIiLwT WasFFMboUsnux0dnPQbZ0i0YKKym92z0j5QZjsHbGYtwhOevBulRnA/9FhNQsS1jkLTk t9UwcD42xsJYeDs/foqm+wAH517qKh+Su0YWBSGyGg640KuoA2cu8XtdeAk8lCMF9Wq+ yNmA==
X-Gm-Message-State: ANoB5pnflPvPPWmMLkEMzWjUxiqdb9Nl82MZez68RVpRY1y4HTzTuVqU zyMOsucK9neosMtherxdjRbHZ6ztAA1ZlourtG9K3S+wKvDq0A==
X-Google-Smtp-Source: AA0mqf4HcvJXcYrFnMIZqBtFZCF638PWsaRCniw1MF6vBs/fGCYgU9delRAc1oaBAh+6YvLfOqbRPMKV55HCe9j2wtQ=
X-Received: by 2002:a17:906:9484:b0:7ae:6c36:3e09 with SMTP id t4-20020a170906948400b007ae6c363e09mr4108791ejx.385.1667831348044; Mon, 07 Nov 2022 06:29:08 -0800 (PST)
MIME-Version: 1.0
References: <CAPz_-SU7rctchBVvm59YAoEA7p8Or9aqdGovJ2E98Tp85jVsWQ@mail.gmail.com> <Y2jCtzeJZfz2daYJ@localhost>
In-Reply-To: <Y2jCtzeJZfz2daYJ@localhost>
From: David Venhoek <david@venhoek.nl>
Date: Mon, 07 Nov 2022 14:28:58 +0000
Message-ID: <CAPz_-SVkFZaycpimBGy-pZRgwxo9pdnrmh7QDd-=+qvXfdFKRw@mail.gmail.com>
To: Miroslav Lichvar <mlichvar@redhat.com>
Cc: ntp@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/Fk5n5qkRExb4Sr8rFnfeAFmQTWc>
Subject: Re: [Ntp] NTPv5 draft suggestion to move timescale offset into extension fields.
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2022 14:29:13 -0000

In response to ulrich, NTPv4 has a similar restriction where normal
clients should not synchronize to strata higher than 15. However, that
was not yet part of the NTPv5 draft, the comment here was merely to
suggest that clients should not synchronize to servers with strata
higher than that, even though we can now represent (just like in
NTPv4). I am not really sure what you mean with the mapping part of
your comment, if I missed something important there could you please
elaborate?

As for not using a new timetype, that could work, however, then we
need to include an era number to ensure that the indicated timestamp
is unambiguous. Given that, I would then prefer not to cram the
timescale id in the extension field code but just keep both of them in
the extension field.

On Mon, Nov 7, 2022 at 8:33 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> On Sun, Nov 06, 2022 at 02:25:11PM +0000, David Venhoek wrote:
> > + 0                   1                   2                   3
> > + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> > ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > +| Type = [[TBD]] (draft 0xF50A) |           Length = 16         |
> > ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > +|   Reference   |    Target     |           Reserved            |
> > ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > +|                                                               |
> > +|                  Offset (time64)                              |
> > +|                                                               |
> > ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> I'm thinking, instead of using a new 64-bit type for the offset,
> wouldn't it be better/cleaner to provide this information in the form
> of an extra receive timestamp in the requested timescale, similarly to
> the already specified monotonic timestamp? The client can calculate
> the offset as the difference between the two receive timestamps it
> requested.
>
> This might slightly simplify the server logic as there is only one
> operand instead of two.
>
> The monotonic timestamp field could be merged with this field as a
> special server-specific timescale.
>
> To avoid wasting 24 bits in the field, the timescale could be encoded
> in the type, i.e. with each new supported timescale a new extension
> field would be defined, up to 256 types.
>
> --
> Miroslav Lichvar
>