Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex

Danny Mayer <mayer@pdmconsulting.net> Sun, 26 September 2021 16:24 UTC

Return-Path: <mayer@pdmconsulting.net>
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 E34703A2A98 for <ntp@ietfa.amsl.com>; Sun, 26 Sep 2021 09:24:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, 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 sSeMV4tXW4Nn for <ntp@ietfa.amsl.com>; Sun, 26 Sep 2021 09:24:39 -0700 (PDT)
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 8AF743A2A96 for <ntp@ietf.org>; Sun, 26 Sep 2021 09:24:29 -0700 (PDT)
Received: from newusers-MacBook-Pro.local (pool-108-26-179-179.bstnma.fios.verizon.net [108.26.179.179]) (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 4HHWLc410vzMNXf; Sun, 26 Sep 2021 16:24:24 +0000 (UTC)
To: Watson Ladd <watsonbladd@gmail.com>
Cc: Marcus Dansarie <marcus@dansarie.se>, NTP WG <ntp@ietf.org>, JP Sugarbroad <taralx@gmail.com>
References: <CAGZkp1-ZCuSvMyQyWCnE511O8-WL=OXfsTdraKsByMmWC3spVA@mail.gmail.com> <CACsn0ckZmR=k2NAmdyhVOA=V_XQ18AnBUBSTOu+bDXS1YsPpUg@mail.gmail.com> <CAGZkp18eASaF7qvubYpDgzvg643ZXuPwDs9qsiC1P_AVLcywLA@mail.gmail.com> <CACsn0cnjHFwxHT13nMavRFzRteWJ=SORY8v4RCZjdjYP0H3oaw@mail.gmail.com> <7dde7eb3-4dc7-94d3-e63a-6d5d0736b1c2@pdmconsulting.net> <54baf1fa-b138-4eb8-6f4e-99168cf2db7b@dansarie.se> <0a95d35f-f708-4a3c-4ecf-77597c42a7a4@pdmconsulting.net> <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com>
From: Danny Mayer <mayer@pdmconsulting.net>
Message-ID: <79dfd56c-54e8-8b85-ed9d-da9fac71d1f1@pdmconsulting.net>
Date: Sun, 26 Sep 2021 12:24:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <CACsn0c=gdQWDumfzeHYYWzXPV4sz4J9mTUtYW+4=KueaHHbGdQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------DA8C5C9A66499D43876F76D5"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/GcczIFSIVnOQmGfGnImVvt7WDfM>
Subject: Re: [Ntp] draft-ietf-ntp-roughtime-05: tag change makes implementation more complex
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: Sun, 26 Sep 2021 16:24:47 -0000

On 9/25/21 12:21 PM, Watson Ladd wrote:
> On Wed, Sep 22, 2021, 8:00 AM Danny Mayer <mayer@pdmconsulting.net> wrote:
>>
>> On 9/21/21 3:24 PM, Marcus Dansarie wrote:
>>> I'll hijack this thread in an attempt to answer a number of related
>>> Roughtime questions in the same place. Apologies in advance for that.
>>>
>>> On 2021-09-21 16:27, Danny Mayer wrote:
>>>> It would be helpful if you explained why you changed it in the first
>>>> place. I assume you had a good reason to do so.
>>> I was the one to initially suggest terminating the PAD tag with zeros
>>> instead of ones (0xff) back in 2019:
>>>
>>>> The PAD tag key is encoded as PAD\xff, while the SIG tag key is
>>>> encoded as SIG\x00. For consistency, this should be changed so that
>>>> both are terminated with \x00. Additionally, terminating the tag keys
>>>> with the NULL character will make displaying them easier on many
>>>> platforms.
>>> In short, terminating all "ASCII-style" tags shorter than four
>>> characters with zeros allows for unambiguous translation into 32-bit
>>> integer tags. The entire message is archived at:
>>> https://mailarchive.ietf.org/arch/msg/ntp/BSYmaFGoEYHNECg2Mc2qgjzQZh4/
>> It would make more sense to make all of the tags 4 ascii characters and
>> be done with it. I also don't understand the need for PAD and that the
>> message has to be at least 1024 bytes in length. The length of the
>> message is included in the packet so such a requirement is unnecessary.
> NUL is an ASCII character :-P.

So is VT. I'm not even sure why you want ASCII characters for tags. They 
can just as easily be represented by numbers. If you use an 8-bit size 
you can have up to 255 tags and therefore compress the amount of space 
needed in the packet.

I find this statement (in Section 6.2.5) to be a bit strange: "The MIDP 
tag value MUST be timestamp of the moment of processing." What does that 
mean? It could mean any time between receiving the packet to sending the 
packet. Since you don't appear to be sending a receive timestamp or 
sending timestamp you can't get an idea of the round-trip time. Between 
Earth and Mars that's a large number, relatively speaking but this 
proposal doesn't seem to take account of that at all. If you don't care 
about round-trip time you should say so explicitly in the draft.

>
> Padding is necessary to ensure that servers never send back replies
> bigger than responses. The minimum length is to ensure that most
> responses will fit. Why we do it in the message and not the packet is
> partially historical: Marcus and I will at some point revisit this
> along with some other choices.

According to the diagram in Section 6, you do specify the length of the 
message. I'm not clear why you are wasting 8 bits at the beginning to 
say 'ROUGHTIM', what else would it be? You are better off using that 
space to specify roughtime versioning information.

Danny