Re: [Ntp] NTPv5 draft move timescale into flags

David Venhoek <david@venhoek.nl> Sat, 05 November 2022 12: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 62D22C14CE43 for <ntp@ietfa.amsl.com>; Sat, 5 Nov 2022 05:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 fQtHpYxKTC2d for <ntp@ietfa.amsl.com>; Sat, 5 Nov 2022 05:29:15 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 93215C14CF00 for <ntp@ietf.org>; Sat, 5 Nov 2022 05:29:14 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id sc25so19409117ejc.12 for <ntp@ietf.org>; Sat, 05 Nov 2022 05:29:14 -0700 (PDT)
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=h20xfUpwzM7DPkZ++GaUrEaiDuNhHakd/3By7Mr0edw=; b=6JgRb5/y9x2jZqlMu7dHAKY81TlALsd2zGfAFM5o4a2kcSoOjJUflYegn1TZx2O1Mn 3FRZGefO2ijvsJXbbVLdqVUq9xjhOYaZIchhNnj7DjGcd1OaMcg3eKtMxjb0P6kXU3UH 4z3y67bNADvSFpvPvXQyUdSRHD8fcZQt2GXc32HWwDQzw8J5QUiMF5ny8a8SGBTtMMhp YCv11cAlfQXbZHWIa0YYsyx326uJwQ8owwkLh0eiKblVGtPq3tz8uEqy6XDH03StkEqb 7jj3+evc/8Pzb3VZfMmQ2msgI3wTxifEn1KTJl3woRT77rFrFKOFPugfdxyRoLSizhPn CazQ==
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=h20xfUpwzM7DPkZ++GaUrEaiDuNhHakd/3By7Mr0edw=; b=xfA5xl/55f3tDj799MxTwRE7fKbsmJLD7q9byBcHz5fhTyA9PiUr9CHpztye5zIfLg 3Tagpsw8HnjunTX/tiDEsWICKn8UXnTjxrG7+x2pdjT/CFBXX82itp6C/kVYLdb5BnHd rQn03HGRQ5bKBXTqFa1Dwm0I6WnwWkwAk4Z2iBaiQDY0IZO7sJUJg6YGtg/XGlJFMAaE PJTOQs0CgONVfDC8KtG6mSmwlvy6VwRhcMlAJu6pPH+FKjWoK5UrdDwsxESRT4wD+PHt 5F/HK62UH89w/duwmYSptWSjTSdg5ozkXvi6O36sJYjCVEu6W8G+cVEjo35owjtAjLXZ YQwg==
X-Gm-Message-State: ACrzQf1ciky8MDKlgyaAwnznuQJBHfLDKNM0Jf7YDgW7N/fBX8UbFFT1 hv+Jlv/LsqN9CA9h2uEi5MkSxs8kwzzLxEakQ3Uycg==
X-Google-Smtp-Source: AMsMyM68kfS6gjrN44qonH0JB3DqvhwqzPq4UuAP/yCRKkXw/a4JHRAB6bMpje+Sw08tU4zDqge+B9piOk8aE6Kl8Nw=
X-Received: by 2002:a17:907:7da6:b0:791:997e:58fc with SMTP id oz38-20020a1709077da600b00791997e58fcmr39844252ejc.385.1667651353179; Sat, 05 Nov 2022 05:29:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAPz_-SU-J46nT__7-AtxFmPBYn_5x_HwgMhjSLEzBsX3R93Rbg@mail.gmail.com> <Y2YyNIluvvwJbKvl@localhost>
In-Reply-To: <Y2YyNIluvvwJbKvl@localhost>
From: David Venhoek <david@venhoek.nl>
Date: Sat, 05 Nov 2022 12:29:09 +0000
Message-ID: <CAPz_-SWMpCUoLCFhhvQLZJC2TS6KYeRhLMe72ZBhADR8rwfVAA@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/AlYv_Nyx047MLjAPFEpRSj0DsJM>
Subject: Re: [Ntp] NTPv5 draft move timescale into flags
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: Sat, 05 Nov 2022 12:29:17 -0000

I don't agree on you with 16 values being more than enough for the
timescale field. There are further timescale not currently included in
the draft (like the global navigation timescales) which people might
very well want to use, and if you then also want to have some amount
of experimental/private use range, we fill up the available space
quite quickly. (With just the global navigation timescales added, we
would already be at 8, and having at least 4 experimental ones feels
like a necessity to me, so that already brings us to 3/4 full) I do
really think we should allocate at least some more bits to this
fields.

As for the stratum, I did not mean to suggest that we raise the
default range of valid strata to beyond 16. However, I have used in
the past higher strata values during testing, just to make sure
nothing accidentaly would pick up my test server except clients I had
specifically modified/configured to accept a custom stratum range. If
we have the option I think that is worth preserving.

On the flags field, I don't really see the use for keeping more flags
available. If an extension needs to send additional/different data
from the normal ntpv5 fields we need extension fields anyway. Should
we ever have an extension that really only needs flags, I am
comfortable making the sacrifice of needing a full extension field
(which really only needs to be 4 bytes if it is a single flag anyway)
for that.

Kind regards,
David Venhoek

On Sat, Nov 5, 2022 at 10:51 AM Miroslav Lichvar <mlichvar@redhat.com> wrote:
>
> On Fri, Nov 04, 2022 at 12:19:59PM +0100, David Venhoek wrote:
> >  - We keep the full 8 bits available for stratum, thus allowing
> > parties that want to work with higher stratum ranges to still do so.
>
> Do you have any examples of applications that would need such high
> strata? I don't remember seeing any complaints about 16 being too
> small. Is this about the idea of providing the maximum value + 1 from
> all selected sources instead of the single best source?
>
> There are some considerations that need to be made, e.g. if loop
> detection was not working (reliably) for any reason, it would take 16
> times longer to reach the maximum.
>
> > - Because the flag field is relatively under-used, a full 6 (or even
> > 7, depending on what we do with interleaved modes and the server
> > cookie) can be used for timescale identification, leaving more room
> > for future expansion and/or a private/experimental-use range.
>
> I don't like leaving no room in flags for future extensions. Older
> versions of the draft used 2 flags for the followup mode and I can
> image new features needing more. I'd consider 8 bits for flags as the
> minimum.
>
> The timescale field should be ok with 3, and 4 would be plenty for
> future.
>
> --
> Miroslav Lichvar
>