Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

Harlan Stenn <stenn@ntp.org> Mon, 31 August 2015 19:46 UTC

Return-Path: <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>
X-Original-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Delivered-To: ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B45B31B2C96 for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Mon, 31 Aug 2015 12:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 m4EpWJr3zwAA for <ietfarch-ntp-archives-ahFae6za@ietfa.amsl.com>; Mon, 31 Aug 2015 12:46:03 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [IPv6:2001:4f8:fff7:1::7]) by ietfa.amsl.com (Postfix) with ESMTP id 48ED11B5A90 for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 31 Aug 2015 12:46:01 -0700 (PDT)
Received: from lists.ntp.org (lists.ntp.org [149.20.68.7]) by lists.ntp.org (Postfix) with ESMTP id D481586DBBD for <ntp-archives-ahFae6za@lists.ietf.org>; Mon, 31 Aug 2015 19:46:01 +0000 (UTC)
X-Original-To: ntpwg@lists.ntp.org
Delivered-To: ntpwg@lists.ntp.org
Received: from stenn.ntp.org (stenn.ntp.org [IPv6:2001:4f8:fff7:1::30]) by lists.ntp.org (Postfix) with ESMTP id F181986D77B for <ntpwg@lists.ntp.org>; Mon, 31 Aug 2015 19:19:52 +0000 (UTC)
Received: from localhost.ntp.org ([::1] helo=stenn.ntp.org) by stenn.ntp.org with esmtp (Exim 4.85 (FreeBSD)) (envelope-from <stenn@stenn.ntp.org>) id 1ZWUcQ-0003MW-Ti; Mon, 31 Aug 2015 19:19:50 +0000
From: Harlan Stenn <stenn@ntp.org>
To: Miroslav Lichvar <mlichvar@redhat.com>
In-reply-to: <20150831135058.GA11596@localhost>
References: <20150721092341.17016.69271.idtracker@ietfa.amsl.com> <20150827143339.GS24378@localhost> <700776e0c93c416f84a1f763c6644df8@IL-EXCH02.marvell.com> <20150831135058.GA11596@localhost>
Comments: In-reply-to Miroslav Lichvar <mlichvar@redhat.com> message dated "Mon, 31 Aug 2015 15:50:58 +0200."
X-Mailer: MH-E 7.4.2; nmh 1.6; XEmacs 21.4 (patch 24)
Mime-Version: 1.0 (generated by tm-edit 1.8)
Date: Mon, 31 Aug 2015 19:19:50 +0000
Message-Id: <E1ZWUcQ-0003MW-Ti@stenn.ntp.org>
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt
X-BeenThere: ntpwg@lists.ntp.org
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <ntpwg.lists.ntp.org>
List-Unsubscribe: <http://lists.ntp.org/options/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=unsubscribe>
List-Archive: <http://lists.ntp.org/pipermail/ntpwg/>
List-Post: <mailto:ntpwg@lists.ntp.org>
List-Help: <mailto:ntpwg-request@lists.ntp.org?subject=help>
List-Subscribe: <http://lists.ntp.org/listinfo/ntpwg>, <mailto:ntpwg-request@lists.ntp.org?subject=subscribe>
Cc: "ntpwg@lists.ntp.org" <ntpwg@lists.ntp.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org
Sender: ntpwg <ntpwg-bounces+ntp-archives-ahfae6za=lists.ietf.org@lists.ntp.org>

Miroslav Lichvar writes:
> On Sun, Aug 30, 2015 at 06:21:48AM +0000, Tal Mizrahi wrote:
>>> As for interoperability with existing implementations, shouldn't be
>>> a server allowed to use the extension only when the client request
>>> had it? There are NTP implementations that ignore any replies that
>>> are not exactly 48 bytes.
>> 
>> I understand there are implementations that behave this way, but I
>> could not find such a requirement in RFC 5905 - please correct me if
>> I am wrong.  I am not sure we want the *current draft* to be
>> interoperable with unspec'ed behavior. If we believe this is the
>> correct behavior, we should probably start by updating
>> draft-ietf-ntp-extension-field.
> 
> In draft-ietf-ntp-extension-field-04 there is:
> 
>   If a host receives an extension field with an unknown Field Type
>   value, the host SHOULD ignore the extension field and MAY drop the
>   packet altogether if policy requires it.
> 
> which I think describes what the implementations currently do.
> 
> I think there may be only two options. Either the implementations are
> allowed to drop packets with unknown fields and servers don't use them
> unless requested, or clients are required to accept packets with
> unknown fields and servers are allowed to use them arbitrarily.
> 
> The former has an advantage that it would probably limit the maximum
> traffic amplification ratio.

How does this limit an amplification ratio?

>>> BTW, is anyone working on the "timestamp correction" extension field
>>> that is mentioned in this draft? I'd be very interested in that.
>> 
>> We (at Marvell) have implemented the hardware aspect of this feature,
>> i.e., timestamping an NTP message + updating its checksum complement.
> 
> If I understand it correctly the checksum complement extension field
> makes it easier for you to implement hardware timestamping, which puts
> the timestamp closer to the actual time the packet is sent on the
> wire.

I'd be surprised to learn this would make a significant difference.

If you want to have accurate transmit timestamps with a software NTP
implementation, I think folks will need to use interleave mode.

> Now, the question is how to record the delays in the packet processing
> on the path between the server and the client, i.e. add support for
> NTP "transparent clocks". Something that could be easily implemented
> in routers/switches and wouldn't require tracking of all client/server
> connections. One possibility I think is an extension field which has
> four values: C1, D1, C2, D2.
> 
> - C1/C2 is counting how many times the D1/D2 value was updated and
>   D1/D2 is the accumulated delay in the processing, all zeroed in the
>   client request
> - NTP-aware devices on the path to the server increment C1 and add
>   their delays between receiving and sending the packet to D1
> - NTP server swaps the C1 and D1 values with C2 and D2 in the
>   extension field
> - NTP-aware devices on the path to the client update C1 and D1
> - the client can use the D1 and D2 values to fix the calculated offset
>   and delay. If C1 and C2 are not equal, the client knows the two
>   paths are different and may discard the sample.
> 
> With 1 byte for C1/C2 and 8 bytes for D1/D2 in the NTP timestamp
> format that would be 18 bytes of data. That would fit in the padding
> in the proposed checksum complement field if you were interested in a
> more general form of the "timestamp correction" field.

I'm curious about the use-case for this.
-- 
Harlan Stenn <stenn@ntp.org>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
ntpwg@lists.ntp.org
http://lists.ntp.org/listinfo/ntpwg