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

Harlan Stenn <> Mon, 31 August 2015 19:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B45B31B2C96 for <>; Mon, 31 Aug 2015 12:46:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.31
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m4EpWJr3zwAA for <>; Mon, 31 Aug 2015 12:46:03 -0700 (PDT)
Received: from ( [IPv6:2001:4f8:fff7:1::7]) by (Postfix) with ESMTP id 48ED11B5A90 for <>; Mon, 31 Aug 2015 12:46:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D481586DBBD for <>; Mon, 31 Aug 2015 19:46:01 +0000 (UTC)
Received: from ( [IPv6:2001:4f8:fff7:1::30]) by (Postfix) with ESMTP id F181986D77B for <>; Mon, 31 Aug 2015 19:19:52 +0000 (UTC)
Received: from ([::1] by with esmtp (Exim 4.85 (FreeBSD)) (envelope-from <>) id 1ZWUcQ-0003MW-Ti; Mon, 31 Aug 2015 19:19:50 +0000
From: Harlan Stenn <>
To: Miroslav Lichvar <>
In-reply-to: <20150831135058.GA11596@localhost>
References: <> <20150827143339.GS24378@localhost> <> <20150831135058.GA11596@localhost>
Comments: In-reply-to Miroslav Lichvar <> 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: <>
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: IETF Working Group for Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Cc: "" <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ntpwg <>

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 <> - be a member!
ntpwg mailing list