Re: [Ntp] Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)

Erik Kline <> Thu, 22 July 2021 23:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 472553A1321 for <>; Thu, 22 Jul 2021 16:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mrfz7pRGKzP5 for <>; Thu, 22 Jul 2021 16:54:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE4353A131E for <>; Thu, 22 Jul 2021 16:54:37 -0700 (PDT)
Received: by with SMTP id 68-20020a9d0f4a0000b02904b1f1d7c5f4so425572ott.9 for <>; Thu, 22 Jul 2021 16:54:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H5ep7XbhrugZod4hjq+ZB4W4lgN92kjA4RckDzZmIa0=; b=TbAwY1RiPbJcbzF5T8ytAa5CE6iDqQJOQyCvviGteuvEFmffmFdyXBlSH9PNDokEo6 mnznCD21i2PytPSMIU1NNlM6kLaTXCcdLlVxJBiytthYBeQMkC1ZpNvfcfiRYxS9sEtT LQjoUC4v5Ry70Al8wlyTFqbyOyLI1dxEeQAHAJp/SDzyKSBMvno9SQ2NBLzcd3nHwWwz 8HJ71f5+Jmq/oA4GqVC99c2LYDIl234tAkCUUc5EZH/5Ros3PBJZo/Ayw8/s+uQQDxBC ryKqOkSA3kap2tZF7FMBBZsMnug8BI7mJ7EdwVFusWbSMq2Wh+qxNjOqeMcxNVnnPQgT 9K1w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H5ep7XbhrugZod4hjq+ZB4W4lgN92kjA4RckDzZmIa0=; b=IruLZamvQA22njbGHisxMeFvtfAHORy8lx7udQLLuvckCMPdaNwuFffi4sRMWxuiYd ElyoZwNSKdTkhTWzf2U8t04tZYfAwpR2dvcvq8TvPBIwinvvi4lwKRqvdwhWy9a5jnDp 4mbhYhdMN7i0/beJyq3kXINZip4P3aKvHet5wgAPrbcsEvRsE4gmBeSCEcA44Dkhe1O1 c9Iksi8tNSnzljz2l5q0zXQbllDGgI7zoUlD8IO5HihwQA4OOephBX7tpQtgrOTKvyFK qyPt/IpZGbu7iqDaqAQVy4OmiY2mKTf81jkS5Z0dW4AYZBxOjp99VgxSr8nlJO8uJx41 zoHg==
X-Gm-Message-State: AOAM530ntzcdQym4WDD5dNIIrc9S1aPYez9pKtEzQSe37ZrWY/u4aGaL 3/R8V6/xCq4zF2lanlrxlrGA++K2Kk60GS7oa3E=
X-Google-Smtp-Source: ABdhPJyWiNsc3Mm2RpaCebaCaYhAKscSja4FNN+TrIOgb5q8a29Ex8ntkaNhwovLSVV9RmdTHtUxW9stfvwyIM0LQWw=
X-Received: by 2002:a9d:630f:: with SMTP id q15mr1415487otk.155.1626998076125; Thu, 22 Jul 2021 16:54:36 -0700 (PDT)
MIME-Version: 1.0
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <> <YN3ZzPN5LOsAjmz6@localhost> <> <YPaunrczI/inrtMP@localhost> <> <YPa9H7IV2wITWKrD@localhost> <> <YPkxqtpgzD7g8Anz@localhost>
In-Reply-To: <YPkxqtpgzD7g8Anz@localhost>
From: Erik Kline <>
Date: Thu, 22 Jul 2021 16:54:25 -0700
Message-ID: <>
To: Miroslav Lichvar <>
Cc: Ulrich Windl <>, "" <>
Content-Type: multipart/alternative; boundary="00000000000060b7a905c7bf02d3"
Archived-At: <>
Subject: Re: [Ntp] Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Jul 2021 23:54:42 -0000

On Thu, Jul 22, 2021 at 1:52 AM Miroslav Lichvar <>

> On Wed, Jul 21, 2021 at 12:07:47PM -0700, Erik Kline wrote:
> > >
> > > Of course, this doesn't change anything about compatibility with
> > > existing NTPv4 implementations. There is no clean way to detect the
> > > support.
> > >
> >
> > <random bad idea>
> > For client mode, could the client make use of the LI field to indicate it
> > speaks interleaved?
> > </>
> No, there are clients that always set it to synchronized, other
> clients set it always to unsynchronized, and other clients set it to
> their actual status.

Ah, fascinating.  =)

If we are considering unclean solutions abusing unrelated fields, the
> best one would be the reference timestamp. It is 64 bits and it is
> normally ignored by the server. The NTPv5 proposal uses this field to
> detect whether an NTPv4 server supports NTPv5. Not a clean solution,
> but I don't see a better one. What would IESG think about that?

I'm not yet sure what would ease folks' concerns.

One thing struck me when reading your reply on another thread about using
an extension:

    Using a 28-octet extension field to convey a single bit of information
    is quite wasteful anyway.

While I certainly see this point, it occurred to me that if the extension
where written to be a general "extra flags and fields" extension -- of
which one was defined for "I speak interleaved" and rest reserved -- then
another way to think about it is that the cost of this space would be
amortized across the other future uses of the space.

Of course, that assumes that there would be other uses of the space to come
along and make that amortization happen, and I don't know enough to
speculate with any confidence the likelihood of that...

For the interleaved mode, clients could be required to set it to a
> specific value, maybe XORed with their RX and TX timestamps, to push
> the false positive rate to the 1/2**128 territory. I think this would
> truly make it the hack that same people already consider it.

Operationally speaking, there ought to be one value somewhere between 1900
and ~now that could be blessed with meaning.  But I agree this seems like
"mak[ing] it the hack that same people already consider it."