Re: [Gen-art] Genart last call review of draft-ietf-dtn-bpbis-17

Stewart Bryant <stewart.bryant@gmail.com> Fri, 08 November 2019 12:36 UTC

Return-Path: <stewart.bryant@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0813A12007C; Fri, 8 Nov 2019 04:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 xgpTNgQEw4RD; Fri, 8 Nov 2019 04:36:27 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7930120041; Fri, 8 Nov 2019 04:36:26 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id f2so6829701wrs.11; Fri, 08 Nov 2019 04:36:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTY5KSSkvQyh5ENzjG+Sdgqs/nPz5leVMn+9kbtJcM0=; b=OjnMuaBfiiFMNFYrlbGUrSDBi8UBeUQmqxoCkLsYvnv3PItZ81yauVEkFLpWx03pw+ QWx8bLDN8f9O41WlMcoL32JQWYLOuaFpB0wAEeEXZ66qGeflxi9+lustmvbV0etj/9Tt LCXfWYvApCcejxloQGeUZzH1ebKhz1h12qYP7i0p00khqsRAdRvX0BkIrXskkRfQxz/E afswPfCh8POgvNizBLpE1T93wHKuW3d2UTNzHhC0WWdiO5W7f+FCYb5t7un9FwKqaV/d 7XckvYWbHCBb1kCM0mbSKC7QRSHTkdUfAJoRckg6rDfuh5f+BlwxEFPWHWxeRBp8IIal lJtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xTY5KSSkvQyh5ENzjG+Sdgqs/nPz5leVMn+9kbtJcM0=; b=IFIwN8n8Qscnn0YnklHEZzGKCiEVHkAz/9a4HEbtGukdsCuG6Xd07RwwjehfXhqEdQ QS92L2UjvKYH06y32sTWayrLel+swUXmDEbT4GD4uTolvLE6X/JheD8HQqnPojN+ikf8 Ui/pNAk5Yr2QqWd3OeurgcpMoPEu4BZgYoHeNN8wUbpyRf1cKLW8xMBezUiH2+mO707P rJMXINm/xbrlO+Cwv+NZ2rt/+DXT43fckt2rPR9UaaEX92UREM26YYu7SV8w/HVLqBvK wFsFU7QxpXHdMhO/54jzia7IPKtstn92B6KbwpQMqlmrg+btLDGcgZtswCW3Fg9y84Ux +Wxg==
X-Gm-Message-State: APjAAAX/Ymaxp4zyXp+ocMPC496DQ3HQt83+3irvEnRbmUnVmWxPek+9 TcTwRaWaYzXfuIyR+PZcUgQ=
X-Google-Smtp-Source: APXvYqz5FoS7UCiXsn265OoplwlE0CGEHzdcWZOL5ZQQUzn192PxtF5l+gMhao9QVZ2GEytYbX8/DA==
X-Received: by 2002:adf:9f52:: with SMTP id f18mr7894615wrg.51.1573216585279; Fri, 08 Nov 2019 04:36:25 -0800 (PST)
Received: from [192.168.178.46] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id t24sm9116565wra.55.2019.11.08.04.36.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2019 04:36:24 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
From: Stewart Bryant <stewart.bryant@gmail.com>
In-Reply-To: <65cb92a64e5e6d5010392ad33d70be44c8abc962.camel@ericsson.com>
Date: Fri, 08 Nov 2019 12:35:52 +0000
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dtn-bpbis.all@ietf.org" <draft-ietf-dtn-bpbis.all@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A75165E4-126B-4791-9A6D-7CDF555A431C@gmail.com>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com> <65cb92a64e5e6d5010392ad33d70be44c8abc962.camel@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/CC8uuUN9i_BMHKhPjnfW-NCcmVs>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dtn-bpbis-17
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 12:36:29 -0000

>> 
>> SB> I think you are saying that you use Unix time, but Unix time
>> includes leap seconds by double increment, so I don’t think
>> you are using that because that would give you the measurement
>> error you are concerned about. I think that what you are using is
>> a monotonically increasing time based on the Unix epoch. I think
>> that is what PTP (IEEE1588) is using and PTP might be a better
>> reference. PTP is likely to become more available in spacecraft
>> anyway, since it is finding deployment in precision measurement
>> applications. Thus I am not sure I understand why UET is more
>> accessible on spacecraft than TAI. Presumably the spacecraft are using
>> free-running clocks and so will drift, although I understand that
>> work is in progress to provide time sync to spacecraft for
>> navigation purposes.
>> 
>> The argument in this section seems long and will become dated.
>> Surely all you need to say is that you need a monotonically
>> increasing time system such as TAI or UNIX time(), and out of
>> software convenience you choose the latter. However I don’t
>> think that is what you are actually doing. What I think you are doing
>> is using TAI with a free running clock that you accept will drift.
>> 
> 
> So, when I did the AD review I did raise similar concerns, and the note was
> really intended to answer these questions of why the chosen clock rather than
> TAI or other clock definitions that would avoid some other issues. I got enough
> good answers to progress, but apparently the motivation part isn't clear enough
> to make you comfortable over the choices. 

Hi Magnus

I will address the other points in a later email, but on this I am concerned that WG have a misunderstanding of the timebase they are using. UNIX/POSIX time does have leap seconds it just handles them silently so you will get double increments. However since my follow-up note yesterday, I was wondering how the remote remote system knew to add a leap second in order to keep in track with the local system? Isn’t there a risk that the two systems will drift apart as leap seconds are added locally? Also there is the rollover problem to worry about.

I think the section needs to go to a specialist group for review such as TicToc/NTP to verify that it works exactly as the WG expect.

Best regards

Stewart