Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

"Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov> Mon, 11 November 2019 21:14 UTC

Return-Path: <scott.c.burleigh@jpl.nasa.gov>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549C2120046; Mon, 11 Nov 2019 13:14:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.992
X-Spam-Level:
X-Spam-Status: No, score=-1.992 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 g2-Dd9QyJJhG; Mon, 11 Nov 2019 13:14:32 -0800 (PST)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (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 0763512006D; Mon, 11 Nov 2019 13:14:32 -0800 (PST)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.27/8.16.0.27) with SMTP id xABL9wRR134382; Mon, 11 Nov 2019 13:14:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jpl.nasa.gov; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=InSight1906; bh=8Nk+PTGaROU3OmvdxkFgKQN1CFAPC1rD1n6+QTxyLOc=; b=Qltznw+kQY/ZJz5O7H5VjQIWDpoXnDV71WIa5NKZCO1oGdgj2NEBmjmCcQiyS8qzjrTo pVV0JCf7HkSlUKbW0SI2b5k0qpSihlgeD10X0ZLlzPVMnWB8A2Y64GFr5WLPXaE2OyUf 275qcJKY8P48c9VCJr5jmIuc3+FSj4Q0DXylRDpDUm4BCn59RZz8iz0o9zhFL6OZ+G1G 4aKbfb1Y4PuCPcYyvFZjC08uzjTZuYDkZkf78w9qG7ixR2kFcEO/siTZXW3g+57TTfoJ vuSaIbn5f3kANY8TTd1mn88XeraQK70Aus30vEXG++yCorEA5lzwOq9b1XsZz07pVdD7 FA==
Received: from mail.jpl.nasa.gov (altphysenclup01.jpl.nasa.gov [128.149.137.52]) by ppa02.jpl.nasa.gov with ESMTP id 2w7byerv5s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Nov 2019 13:14:30 -0800
Received: from ap-embx16-sp50.RES.AD.JPL (ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id xABLET5d016789 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified FAIL); Mon, 11 Nov 2019 13:14:29 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp50.RES.AD.JPL (2002:8095:898c::8095:898c) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 11 Nov 2019 13:14:28 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1591.008; Mon, 11 Nov 2019 13:14:29 -0800
From: "Burleigh, Scott C (US 312B)" <scott.c.burleigh@jpl.nasa.gov>
To: "lloyd.wood@yahoo.co.uk" <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org>, "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>, Carsten Bormann <cabo@tzi.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-dtn-bpbis.all@ietf.org" <draft-ietf-dtn-bpbis.all@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17
Thread-Index: AQHVmIAptnbJOlhtckurd8Ka4Zi1BKeGFOTggADmtQD//30/IA==
Date: Mon, 11 Nov 2019 21:14:28 +0000
Message-ID: <0e8eee39f5d34b6aa2f6c092e551a3a6@jpl.nasa.gov>
References: <157306815414.27362.18239257168598208900@ietfa.amsl.com> <65cb92a64e5e6d5010392ad33d70be44c8abc962.camel@ericsson.com> <A75165E4-126B-4791-9A6D-7CDF555A431C@gmail.com> <430992730.1235576.1573218197349@mail.yahoo.com> <EFC9E9F1-D43C-46B4-A38B-53EB76E1D3AD@gmail.com> <17ed0ca2fddc42c5bec46925d10a0458@jpl.nasa.gov> <09400E15-F35D-4746-903B-23203C49EB82@tzi.org> <c1134cff3ca74671aa78e81b9e6f072e@jpl.nasa.gov> <555390559.2744128.1573470306035@mail.yahoo.com> <5e1ef88227c3476090640d466da93e3b@jpl.nasa.gov> <1197531489.3309935.1573506114278@mail.yahoo.com>
In-Reply-To: <1197531489.3309935.1573506114278@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp50.jpl.nasa.gov [128.149.137.140]
X-Source-Sender: scott.c.burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-11_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1910280000 definitions=main-1911110186
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/tDF5KCe1eUEYLqm9uiljhK7DfxY>
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 21:14:36 -0000

Lloyd, you keep good files!

-----Original Message-----
From: lloyd.wood@yahoo.co.uk <lloyd.wood=40yahoo.co.uk@dmarc.ietf.org> 
Sent: Monday, November 11, 2019 1:02 PM
To: lloyd.wood@yahoo.co.uk; Carsten Bormann <cabo@tzi.org>; Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>
Cc: last-call@ietf.org; gen-art@ietf.org; draft-ietf-dtn-bpbis.all@ietf.org; dtn@ietf.org
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

Scott

a reminder:

Ground System Architectures Workshop, March 2009, where you talked delay at Torrance.

https://csse.usc.edu/GSAW/gsaw2009/s6/burleigh.pdf

second to last slide:


"Spacecraft clock drifted more rapidly than expected – over 1 second per day. Revised clock correction deltas had to be uploaded to ION for each tracking pass."


Leap seconds are noise by comparison... but the bundle protocol's reliance on and expectation of accurate time runs deep.


Lloyd Wood

http://lloydwood.users.sourceforge.net/Personal/L.Wood/dtn/






On Tuesday, 12 November 2019, 02:25:33 GMT+11, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote: 





Hi, Lloyd.  I don't recall the EPOXI clock drifting that quickly, but certainly it did drift and we did upload clock corrections.  The flow of bundles was not dependent on those corrections; it is not hard to add margin in the time-to-live when bundles are sourced.  But improving the accuracy of the clocks did improve network utilization by enabling the spacecraft to start and stop communication at the beginning and end of each contact rather than a few seconds early or late.

Scott

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of lloyd.wood@yahoo.co.uk
Sent: Monday, November 11, 2019 3:05 AM
To: Carsten Bormann <cabo@tzi.org>; Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
Cc: last-call@ietf.org; gen-art@ietf.org; draft-ietf-dtn-bpbis.all@ietf.org; dtn@ietf.org
Subject: Re: [dtn] [Last-Call] [EXTERNAL] Re: Genart last call review of draft-ietf-dtn-bpbis-17

 (That wikipedia page thinks POSIX *is* unix time, and the cited reference
 doesn't seem to support that claim. Anyone want a wikipedia edit war?)


 Scott, when you did the Deep Impact/Epoxi DTN experiments, the
 spacecraft clock was drifting by over a second a day, and clock
 corrections were uploaded before you could do image uploads.
 Yes, notoriously unreliable -- in a harsh environment.


 But this is now going to be addressed with atomic clocks?
 So this is fixing software design problems in hardware?


 I don't have a solution to what I think are difficult problems.
 But I'd rather not see the protocol problems be glossed over.


 Lloyd Wood
 http://lloydwood.users.sourceforge.net/Personal/L.Wood/dtn/



On Sunday, 10 November 2019, 08:54:36 GMT+11, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote: 





Thank you, Carsten.  Some notes in-line below.

Scott

-----Original Message-----
From: Carsten Bormann <cabo@tzi.org> 
Sent: Saturday, November 9, 2019 12:31 AM
To: Burleigh, Scott C (US 312B) <scott.c.burleigh@jpl.nasa.gov>
Cc: gen-art@ietf.org; draft-ietf-dtn-bpbis.all@ietf.org; dtn@ietf.org; last-call@ietf.org
Subject: Re: [dtn] [EXTERNAL] Re: [Last-Call] Genart last call review of draft-ietf-dtn-bpbis-17

On Nov 8, 2019, at 16:34, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org> wrote:
> 
> I disagree.  From Wikipedia:
>  
> Unix time (also known as Epoch time, POSIX time,[1] seconds since the Epoch,[2] or UNIX Epoch time[3]) is a system for describing a point in time. It is the number of seconds that have elapsed since the Unix epoch, that is the time 00:00:00 UTC on 1 January 1970, minus leap seconds. Leap seconds are ignored,[4] 

There is a problem with this phrase.
You cannot “ignore” leap seconds if you want Posix time.
To the contrary, you need to subtract every single one of them from the number of seconds you count from the Epoch.

    -->  I see your point: Epoch time is simply the number of seconds that have elapsed since the Unix epoch, period.  The "minus" is confusing; "omitting" would have been a little better.

    -->  If you don't have Epoch time, and instead only have UTC, then in order to convert from UTC to the equivalent Epoch time you have to add to your UTC value the applicable number of leap seconds; UTC runs slightly behind Epoch time because it counts more seconds (the leap seconds), which Epoch time does not count.  (At the moment of leap second insertion it takes 2 seconds for UTC to advance from 23:59:59 to 00:00:00 [because the advance from 23:59:59 to 23:59:60 is additionally counted], while over that same 2-second interval the Epoch time will have advanced from 23:59:59 to 00:00:01.)  If you have Epoch time, then in order to convert from Epoch time to the equivalent UTC you have to subtract from your Epoch time value the applicable number of leap seconds, thus retroactively "counting" them.

Leap seconds are actively *not counted*, not “ignored”.
Of course, if you think “ignore” means “not count”, you will think the sentence makes sense.

    -->  Yes.  The sentence could have been written more clearly.

There are time scales that don’t know about leap seconds, such as TAI or GPS (*).
Posix time does know about leap seconds, it needs them to be mostly compatible with civil time (UTC).

(*) The GPS signal indicates the accumulated number of leap seconds since GPS epoch *along with* the monotonic time in GPS time scale (that “ignores” the fact that there are leap seconds).

Sorry for overstressing the semantics here, but from teaching I know that half of the people understand “ignore” as “do not take any notice of”, as TAI does, and only the other half understands that you mean “do not count” as an explicit act of “ignoring”, as in Posix time.

    -->  You're right, an important clarification.

> For example, “The Open Group Base Specifications Issue 7, Rationale: Base Definitions”, section A.4 (General Concepts) says “Coordinated Universal Time (UTC) includes leap seconds. However, in POSIX time (seconds since the Epoch), leap seconds are ignored (not applied) to provide an easy and compatible method of computing time differences.”

“Not applied” has the same problem, maybe slightly less so.

You “apply” leap seconds to Posix time by *not counting* them.

> I am happy to agree that an operating system’s implementation of the time() function may typically obtain accurate UTC time (from GPS or NTP) and subtract the leap seconds out of that value to obtain Epoch time, and in this sense the implementation of the time() function is typically dependent on information about leap seconds.
>  
> But that is an implementation expedient, which BP does not care about.  What BP cares about is expressing time as a number of seconds that have elapsed since the Epoch (minus an offset, the number of seconds elapsed from the Epoch to midnight 1 January 2000 UTC).  The manner in which that value is generated doesn’t matter to the protocol.

That is correct, but it means you can’t have a BP node that doesn’t know about leap seconds (either explicitly or by periodically resetting its clock to the Posix representation of civil time, which in many cases you do anyway because of clock drift).

    -->  Not quite true.  You *can* have a BP node that doesn't know about leap seconds, though I admit that this may not be common.  If the only way to implement the function that returns the current DTN time is to consult UTC time and back the leap seconds out then yes, you need to know about leap seconds.  But if the function that returns the current DTN time does so by consulting an accurate local clock that monotonically increases the count of seconds since the Epoch -- which is, for example, what all deep-space spacecraft clocks effectively do -- then no knowledge of leap seconds is needed.

    -->  Spacecraft clocks have been notoriously unstable in the past, but that is changing.  Radiation-hardened on-board electronics are increasingly reliable.  At the outer edge of what we might contemplate in the near term is the deep-space atomic clock, the first instance of which launched in June (https://www.nasa.gov/mission_pages/tdm/clock/index.html).  It may fairly be argued that an atomic clock the size of a toaster oven, massing 16 kg, is far too large and expensive to deploy on a Cubesat.  I think we find, though, that useful devices like these tend to become smaller and less costly as markets for them emerge.


Grüße, Carsten

-- 
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call

_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn
_______________________________________________
dtn mailing list

dtn@ietf.org

https://www.ietf.org/mailman/listinfo/dtn