Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Message Format

Harlan Stenn <stenn@nwtime.org> Thu, 25 November 2021 05:33 UTC

Return-Path: <stenn@nwtime.org>
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 6AA883A0EDC for <ntp@ietfa.amsl.com>; Wed, 24 Nov 2021 21:33:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.752
X-Spam-Level:
X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 WGNGLXFklwRi for <ntp@ietfa.amsl.com>; Wed, 24 Nov 2021 21:33:12 -0800 (PST)
Received: from chessie.everett.org (chessie.everett.org [IPv6:2001:470:1:205::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71723A0EDA for <ntp@ietf.org>; Wed, 24 Nov 2021 21:33:11 -0800 (PST)
Received: from [10.208.75.157] (075-139-201-087.res.spectrum.com [75.139.201.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4J063S628CzMNRr; Thu, 25 Nov 2021 05:33:08 +0000 (UTC)
Message-ID: <f423daea-93f4-4dd8-9ee6-d654e8e566db@nwtime.org>
Date: Wed, 24 Nov 2021 21:33:07 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0
Content-Language: en-US
To: ntp@ietf.org
References: <20211124223810.Horde.KKjrsykVQUMJgW4WVO5ZZmt@mail.drown.org>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <20211124223810.Horde.KKjrsykVQUMJgW4WVO5ZZmt@mail.drown.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/VfPf_nfiw9tRAdX6IYfnSc7JIOE>
Subject: Re: [Ntp] comments on draft-mlichvar-ntp-ntpv5-03 / Message Format
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Nov 2021 05:33:18 -0000

This is what happens when the choice is made to ignore the design of NTP 
packet version "evolution".

The original design is that the packet format to the length of a version 
N packet is ALWAYS the same.  This is why ntpd will respond to a 
"higher" version number packet with the requested newer version but with 
a packet length of the responding ntpd's version.

If a v4 NTP packet is 48 bytes, the design and expectation has been that 
if v5 wants any different data then the packet is made longer and the 
new data lives AFTER the v4 data.

Assume, for purposes of this thread, that an NTPv5 packet format is now 
64 bytes.

Should a v5 client send a request to a v4 server, the v5 client sends a 
64-byte v5 request, and assuming the v4 server responds, it will do so 
with a 48-byte v5 response that is effectively a v4 response packet. 
The client will see this, note that the packet is short, and be in a 
position to understand that the target server is a v4 server, not a v5 
server.

Should a v4 client send a request to a v5 server, the v5 server should 
respond with a 48-byte v4 response.

H

On 11/24/2021 8:38 PM, Dan Drown wrote:
> This email will be on the "4. Message Format" section.
> 
> Right now the flags/era/timescale fields come before root dispersion and 
> root distance. This puts them at a different offset in the packet 
> compared to their location in NTPv4. Was there a reason not to keep 
> these at the same offset? It's not an implementation problem, just a 
> cosmetic difference.
> 
> For timescale offset, there is an overlap with the unknown value 
> (0x8000/-1.0 seconds) during a negative leap second smear. Is this worth 
> mentioning in the rfc?
> 
> Transmit Timestamp currently has: "In responses it is the time when a 
> response to the client was transmitted. The specific response depends on 
> the selected mode (basic or interleaved). The timestamp corresponds to 
> the beginning of the transmission"
> 
> I'm suggesting this rewording: "In responses it is the beginning of the 
> transmission of a response to the client. Which response it refers to 
> depends on the selected mode (basic or interleaved). See Measurement 
> Modes section below for detail."
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!