Subject: [TICTOC] FW: [dtn-interest] TICTOC Timing Requirements

From: "Airst, Malcolm J." <[email-masked]>
Date: Mon, 8 Dec 2008 21:12:23 -0500

Note reply from Eddy Wesley (NASA) below. He sees no real DTN requirements for TICTOC except that TICTOC allow for one-way time transfers (no ACK needed)...

Sincerely,
Malcolm

********************************************************
Malcolm J Airst,
The MITRE Corporation,
49185 Transmitter Rd.,
San Diego, CA 92152-7335
 
(619) 758-7822 (w)
(619) 318-3837 (c)
(619) 222-2260 (f)
********************************************************

-----Original Message-----
From: Eddy, Wesley M. (GRC-RCN0)[VZ] [mailto:[email-masked]] 
Sent: Tuesday, November 25, 2008 10:30 AM
To: Airst, Malcolm J.; [email-masked]
Subject: RE: [dtn-interest] TICTOC Timing Requirements

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On 
>Behalf Of Airst, Malcolm J.
>Sent: Thursday, November 20, 2008 3:26 PM
>To: [email-masked]
>Subject: [dtn-interest] TICTOC Timing Requirements
>
>Following up on my request this morning: Please send me any 
>DTN timing information and I'll be glad to send to the TICTOC 
>List and convey any comments. 
>

After reading the latest TICTOC requirements draft, I don't
think there should be any requirement on TICTOC for supporting
DTN time synchronization.  The TICTOC requirements are broken
down by the "application" driving them, and if you considered
synchronizing DTN bundle agents to be one of those applications,
then the requirements would be orders of magnitude easier than
for the other applications like cellular towers.  The cellular
backhaul requirements have things like a time accuracy on the
order of microseconds, and frequency stablity in a few dozen
ppb, both of which vastly exceed what bundle agents need.  The
only unique aspect of DTN that influences the capability to use
TICTOC is that unidirectional time-transfer should be possible
(not requiring real-time acknowledgements, or any feedback
channel at all).  It seems like this will be the case for some
of the already-identified TICTOC applications like Time-of-Day,
"legal time", and metrology, where a master clock signal is
distributed out to essentially slave nodes.  The TICTOC
requirements don't seem to exactly say that unidirectional
time-transfer needs to be supported, but as multicast is a
natural fit given a single source and dozens/hundreds of sinks,
it seems like it will develop to permit unidirectional use on
its own.

A DTN has 2 needs for timing signals:

1) A bundle agent can have start times or periodicity associated
   with some of its contacts with other bundle agents.  In order
   for a system to do things like turn radios on, point antennas,
   etc., it will need an accurate sense of time.  If these
   activities occur outside the bundle agent, some means of
   synchronizing the bundle agent's actions with the rest of the
   system is needed.  If the bundle agent runs within the same
   computer that performs these other actions, then the system
   clock itself is sufficient.  In the worst case, the bundle
   agent will likely still be part of an integrated unit with
   the rest of the system that controls antennas, amplifiers,
   etc. and can use some local time distribution means to keep
   in sync onboard a spacecraft or other deployment platform.

   However, the bundle agent on the other end of the contact may
   also need to have its communications equipment configured at
   the same time in order for the contact to start right away.
   Any skew in system times can cut into the usable contact time.
   But since, by definition, the bundle agents aren't in contact
   before the scheduled contact time, there's not much hope of
   something like TICTOC keeping them in sync because it can't
   create comm links where none exist :).  Once the links are
   up, time-transfer could be used to correct for any skew and
   help future contacts, but some damage may have already been
   done to the current contact.

   For this, the only requirement on using TICTOC would be
   that it allow for unidirectional time-transfer, not relying
   on acknowledgements.  How time-transfer signals are treated
   is a thornier operational problem for DTNs, as we cannot
   always assume a simple master-slave relationship where one
   side of a contact always delivers clock and the other always
   accepts it.  But this is mostly a policy issue in each
   particular case of DTN deployment.

2) When a bundle agent creates a bundle, it adds a "creation
   timestamp" to the bundle, as well as a "lifetime" after
   which the bundle is considered to be expired, and discarded.
   These fields are checked by intermediate and destination
   bundle agents.  Some potential issues that can come from
   clock skew involve:

   - "bundles from the future" where a sender's clock gets ahead
     of another bundle agent on the path's and so the creation
     timestamp appears to be in the future.  Some systems may
     choose to discard these as invalid.

   - "bundles thrown out too soon" where a sender's clock is
     too far behind another bundle agent on the path's relative
     to the expiration lifetime.  In this case, bundles can be
     discarded before the sender intended them to be.  This can
     affect applications that set a short lifetime such as
     dtnping, VoBP/VoDTN (Voice over Bundle Protocol / DTN), etc.

   The correct way to deal with this is by changing the semantics
   of the creation timestamp and lifetime fields in the bundle
   protocol (I believe Joe Ishac described this some time ago),
   rather than levy any requirement on TICTOC which would be
   difficult to define or achieve given the intermittently-
   connected, spatially-dispersed, and possibly mixed ownership
   and control of nodes in a "typical DTN".

_______________________________________________
TICTOC mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tictoc