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

Miroslav Lichvar <> Wed, 21 July 2021 09:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06DF63A0C29 for <>; Wed, 21 Jul 2021 02:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.55
X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id prpCc7UvIUKi for <>; Wed, 21 Jul 2021 02:18:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E14CB3A0C2A for <>; Wed, 21 Jul 2021 02:18:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1626859095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=o8UqKB6d+wgszGXyqQAO6nFJGbB7UFhbo4qftMHnuC4=; b=aYIgtl5amFjgY7soZgbVWglEKvPjqW7K0wxVQ/ljKNUkDrlz6FnNrT9BuGMML7q8DQviep EoOUNbcn/FFAnpkoKIfEc4lB7pvegDNW2uVuJFCQ0rOc1v8kKu6n4JXNtoccZc/yEWO6zF jlxY4cgfMvKoDLXXiaktHMDJ9Vb2z+g=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-509-REa9fMbWNieBdCPs9w8tLQ-1; Wed, 21 Jul 2021 05:18:14 -0400
X-MC-Unique: REa9fMbWNieBdCPs9w8tLQ-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BED0A1005D5E; Wed, 21 Jul 2021 09:18:12 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 333DC19D7C; Wed, 21 Jul 2021 09:18:10 +0000 (UTC)
Date: Wed, 21 Jul 2021 11:18:08 +0200
From: Miroslav Lichvar <>
To: "Rob Wilton (rwilton)" <>
Cc: "Eric Vyncke (evyncke)" <>, Warren Kumari <>, The IESG <>, "" <>, "" <>, "" <>, "" <>
Message-ID: <YPfmUK889qx7r5x2@localhost>
References: <YNw9fHMijDFIW9B4@localhost> <YNrbjCDF4/609dg/@localhost> <> <YN3ZzPN5LOsAjmz6@localhost> <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] 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: Wed, 21 Jul 2021 09:18:22 -0000

On Fri, Jul 16, 2021 at 09:39:47AM +0000, Rob Wilton (rwilton) wrote:
> Regarding the issue with the extension mechanism, another possible choice could be for the client to try and open two parallel sessions, one using a new extension field, and one without.  The client could then monitor the responses to the two sessions and choose whether to use the other with the extension or not.

To me that doesn't look like a very practical solution. It wastes
bandwidth. SNTP clients use only one server and might not easily be
modified to work with multiple associations. In case of a heavy packet
loss, the client would be randomly switching between the two
associations, or if it stuck to the interleaved mode once it was found
working, it wouldn't fall back to RFC5905 if the server lost the
support (e.g. after changing implementation implementation or
reconfiguration), so it would have to restart the parallel association

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

> Hence, I propose three possible alternatives:
> (1) Change this document to somehow make use of NTPs extension mechanism and continue down the path of publishing as a proposed standard.  This, I think, would probably entail taking the document back to the WG.
> (2) Change the document status to Informational rather than Standards Track, modifying the text to focus on documenting how some implementations work rather than as an endorsement from IETF that this is the right way to modify the NTP protocol.
> (3) Alternatively, if the authors/WG believe that publishing that document as proposed standard is definitely the right choice, then I would be willing to change my ballot position to abstain.  I.e., I don't agree with what is being done here, but neither will I block progression of the document, given that you say that this modification does not cause operational issues in practice.

If those are the only options, the preference of the WG seems to be
the second one.

Could you please clarify why you don't see the proposal as the right
way? Do you agree with the RFC5905 interpretation that Daniel Franke
pointed out in his objection, that SNTP clients are free to put
anything in the origin timestamp because the "An SNTP client can
operate with any subset of the NTP on-wire protocol" doesn't have


Miroslav Lichvar