Re: [Ntp] Drafts on interleaved modes and correction field

Miroslav Lichvar <mlichvar@redhat.com> Thu, 09 November 2017 09:38 UTC

Return-Path: <mlichvar@redhat.com>
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 AA75C12ECC6 for <ntp@ietfa.amsl.com>; Thu, 9 Nov 2017 01:38:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 bw3EVycbNCKL for <ntp@ietfa.amsl.com>; Thu, 9 Nov 2017 01:38:55 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946FE12ECA9 for <ntp@ietf.org>; Thu, 9 Nov 2017 01:38:54 -0800 (PST)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 54FB4683F5; Thu, 9 Nov 2017 09:38:54 +0000 (UTC)
Received: from localhost (unknown [10.43.2.117]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6D3785FFF1; Thu, 9 Nov 2017 09:38:53 +0000 (UTC)
Date: Thu, 09 Nov 2017 10:38:51 +0100
From: Miroslav Lichvar <mlichvar@redhat.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Cc: ntp@ietf.org, Aanchal Malhotra <aanchal4@bu.edu>
Message-ID: <20171109093851.GA17365@localhost>
References: <20171031090139.GD15597@localhost> <CABUE3XmV1sUvq0KAJVrQv1sZ8vK6R8GwR+qeO1huTUgnOdujfQ@mail.gmail.com> <20171031135247.GB7648@localhost> <CABUE3X=pDEL9mcfoTGJw3PbwzHKnDTddr7Aqk71PyEBY77kzSw@mail.gmail.com> <20171031155717.GC7648@localhost> <CABUE3Xmz0YQ4OoDtE2SB-zimsA5yY32M1j3qotv_si4_OiqyHw@mail.gmail.com> <CABUE3XmHAgdowNV7ibfCMA0QGc6L6H=zA4=DZjgXaY8f04Cz5w@mail.gmail.com> <20171106123644.GA16738@localhost> <CABUE3XkCkWoDyJ8cWHJCCjbpoEnt5bJ1JnmuQKseg++oz0BkhQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABUE3XkCkWoDyJ8cWHJCCjbpoEnt5bJ1JnmuQKseg++oz0BkhQ@mail.gmail.com>
User-Agent: Mutt/1.8.3 (2017-05-23)
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 09 Nov 2017 09:38:54 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0K-94CLlCjAOScene4WOEHWzow8>
Subject: Re: [Ntp] Drafts on interleaved modes and correction field
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <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, 09 Nov 2017 09:38:58 -0000

On Wed, Nov 08, 2017 at 07:32:07PM +0200, Tal Mizrahi wrote:
> >If a switch cut through from a faster link to a slower link, it would
> >know the length of the packet and could calculate the (negative)
> >correction before the correction field was transmitted, right?
> 
> Hmmm... So the switch would have to evaluate the packet length based on the
> Length field in the UDP header, and use that in the correction field
> computation.

Good point. Using the UDP length field should be simpler and give the
switch more time to calculate the correction than waiting for the
end of the received frame.

> It would be significantly easier to implement a correction field
> computation based on first-bit-in-to-first-bit-out.

I understand that. The question is if it's worth the incompatibility
that it would create.

> I may be missing something here, but I would argue that if we consistently
> compute the correction based on first-bit-in-to-first-bit-out, the packet
> transmission times on both directions would cancel out, and would not
> affect the symmetry of the computation.

Yes, but only if the client, server and all switches with different
link speeds between them used the beginning of the reception too.

The clients and servers would have to switch between two modes of
timestamping. One for networks where the correction fields is not
supported and one for networks where all switches (with different link
speeds) support it. It's all or nothing. 

On the other hand, a correction field based on the end of the
reception is compatible with timestamping used by existing clients and
servers, and a gradual replacement of switches in the network does not
create an asymmetry.

> Can you provide an example in which this hypothesis is wrong?

Ok, let's say there is a server on 100 Mbit link, a client on a 1000
Mbit link, and a single switch (store-and-forward) between them. The
propagation delay is 100 nanoseconds on both links and the switch has
a constant asymmetric delay of 500/1000 nanoseconds. The client sends
a 1000 bit frame at time X and the server responds with a frame of the
same length at Y. All timestamping is perfectly accurate. 

The intervals of the receptions and transmissions are:

client TX: [X, X+1000]
switch RX: [X+100, X+1100]
switch TX: [X+1600, X+11600]
server RX: [X+1700, X+11700]
server TX: [Y, Y+10000]
switch RX: [Y+100, Y+10100]
switch TX: [Y+11100, Y+12100]
client RX: [Y+11200, Y+12200]

If the correction field was ignored, the delays of the request and
response would be 11700 and 12200 nanoseconds respectively. The
calculated offset would have an error of 250 nanoseconds.

If the switch calculated the corrections from the beginning of the
receptions, the delays would be 10200 and 1200 nanoseconds. The error
in the offset would be 4500 nanoseconds.

If the switch calculated the corrections from the end of the
reception, the delays would be 11200 and 11200 nanoseconds. The offset
would have no error.

This shows that the switch has to timestamp the same point of the
frame as the server and client. Otherwise, the correction field may
actually increase the error in the measured offset.

-- 
Miroslav Lichvar