Subject: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Mar 2014 17:42:46 +0000

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 12, 2014 10:19 AM
To: [email-masked]
Subject: I-D Action: draft-templin-dtntsync-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Delay Tolerant Networking Time Synchronization - Problem Statement
        Author          : Fred L. Templin
	Filename        : draft-templin-dtntsync-00.txt
	Pages           : 5
	Date            : 2014-03-12

Abstract:
   Delay/Disruption Tolerant Networking (DTN) introduces a network model
   in which communications may be subject to long delays and/or
   intermittent connectivity.  DTN nodes include timestamps in the
   bundles of data they send so that correspondents can identify the
   bundles and determine the length of time they have been in the
   system.  However, there is currently no specified strategy for
   synchronizing the clocks between DTN nodes.  This document therefore
   presents a problem statement for time synchronization in DTNs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-dtntsync/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-templin-dtntsync-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 12 Mar 2014 18:27:48 +0000

Fred,  I appreciate the effort, but I think he effort to fix all these
issues and remain backward compatible is probably not the best use of the
community's time including your time.

The following statement is general to all suggested drafts:

I think DTNRG amd RFC5050 have served a great purpose in allowing the
community to play with various concepts related to store, carry and
forward. One prime example of this is all the various extension blocks and
the ability to experiment with various Endpoint Identifiers.  That being
said, I think it is time to use what we learned to do a redo - albeit I
don't perceive there is sufficient energy and resources (funding appears
to have dried up here)to make that happen.  Furthermore, I would be
tempted to wait until ICN gets a handle on named objects as that is
probably a very useful bit of information to use going forward.

Regarding Time Synchronization:

Take a look at the wiki in the dtnbone section:
http://www.dtnrg.org/wiki/DtnBone

A while back I asked what people set their bundle lifetimes to and why.
The result was that most were setting the bundle lifetimes for the
duration of the deployment/experiment.

I also inquired from many if they use the lifetime for routing. That is,
if I have bundle A and Bundle B and Bundle B of equal size.  If bundle B
is going to expire in 2 hours and bundle A in 3 years, in your particular
implementation, is B sent first.  I believe in all cases I was aware of,
It is the bundle that is put in the queue first, the the one that will
expire first.  That is understandable in an initial implementation -
particularly if you are sourcing all bundles from one place and all have
the same size and same lifetime.  It make the software much easier, but,
if DTN ever took off, this would not be the case.  By-the-way, I suspect
this is how most systems have been tested, and probably more often than
not in a connected network. BBN was the only group I know of that was
tying to select bundle lifetimes, buy they only had 1 bit to use, so there
were two settings: 15 minutes of 2 hours.

Anyway, if you step back and look at the problem and how time is used, you
realize it is not needed. Rather, you only need a couple of course
priorities such as: 1) forward immediately or drop (for streaming), 2)
forward within the next minute or two, 3) forward within the next day, 4)
forward when you can (I'll do a cleanup when I defrost the refrigerator,
clean the garage or sell the house).

Time synchronization in the Bundle Protocol serves three purposes:

   1.  Bundle lifetimes keep bundles from looping continuously due to
       routing loops

>>>>  But it does a really bad job.  I can send a small bundle with a long
>>>>lifetime, 100 years, and the path will open in 100 years.

   2.  The lifetime allows the network to purge expired bundles

>>>  Yes, this is what lifetime will do properly

   3.  The creation timestamp is used to uniquely identify each bundle.

>>>> True, but there are probably other, better ways (in a redo)

******************************
William D. Ivancic
Phone 216-433-3494
Fax 216-433-8705
Networking Lab 216-433-2620
Mobile 440-503-4892
http://roland.grc.nasa.gov/~ivancic

On 3/12/14 1:42 PM, "Templin, Fred L" <[email-masked]> wrote:

>dtn-interest mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/dtn-interest

---

From: Daniel Ellard <[email-masked]>
Date: Wed, 12 Mar 2014 14:29:40 -0400

>    presents a problem statement for time synchronization in DTNs.

I think this is too narrow of a statement of the problem: it assumes
that time synchronization is necessary, and then asks how to provide
it, rather than asking the question of whether time synchronization
is truly an essential requirement of DTN in all scenarios, or
whether the function currently provided by real time can, in a
variety of useful and practical deployment scenarios, be provided by
something else.

-Dan

-- 
Daniel Ellard, Ph.D.
Senior Scientist, Network Research
Raytheon BBN Technologies
[email-masked]
617-873-8004

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Mar 2014 20:27:58 +0000

Hi Will,

> From: Ivancic, William D. (GRC-RHN0) [mailto:[email-masked]]
> Sent: Wednesday, March 12, 2014 11:28 AM
> To: Templin, Fred L; [email-masked]
> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement
> 

I think I understand your point of view, but it would also be good
to get a few more opinions. For example, I'm not sure if backward
compatibility is a strict requirement?
 
> said, I think it is time to use what we learned to do a redo

But, would that necessarily entail throwing out everything that
has come before (I wouldn't think so)?

> - albeit I
> to have dried up here)to make that happen.

I don't have enough insight into this to know who would be
willing to take on the effort and what the funding sources
would be. I know I have some cycles, but I also know that it
takes more than one. 

> Furthermore, I would be

I haven't written that problem statement yet, but the ICN work
could certainly fall in the solution space.

> clean the garage or sell the house).

This certainly looks like additional considerations for widening
the problem statement.

> >>>>lifetime, 100 years, and the path will open in 100 years.

Maybe setting healthy limits would be part of a solution proposal?

> >>>  Yes, this is what lifetime will do properly

OK.

> >>>> True, but there are probably other, better ways (in a redo)

I think I understand your point of view. BTW, the three items I
listed above came directly from "Bundle of Problems", but I don't
see why addressing the concerns couldn't be done in an RFC5050(bis)?

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 12 Mar 2014 20:33:20 +0000

Hi Dan,

> From: dtn-interest [mailto:[email-masked]] On Behalf Of Daniel Ellard
> Sent: Wednesday, March 12, 2014 11:30 AM
> To: [email-masked]

I think I understand the concern, and I don't mind expanding the
problem statement.

Thanks - Fred

---

From: Johannes Morgenroth <[email-masked]>
Date: Thu, 13 Mar 2014 14:40:28 +0100

Am 12.03.2014 21:33, schrieb Templin, Fred L:
> Delay Tolerant Networking Time Synchronization - Problem Statement

Just to advertise my own work. There already exist an approach to
synchronize time between DTN nodes published in [1]. It has been
implemented/tested in IBR-DTN and uDTN (wireless sensor nodes).

[1] http://dl.acm.org/citation.cfm?id=2348618

Regards,
Johannes Morgenroth

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Mar 2014 17:39:34 +0000

I would be happy to retire any problem statement for which there is
one or more consensus solution - calling for solutions is the purpose
for posting problem statements in the first place.

Thanks - Fred

> From: dtn-interest [mailto:[email-masked]] On Behalf Of Johannes Morgenroth
> Sent: Thursday, March 13, 2014 6:40 AM

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 13 Mar 2014 18:02:08 +0000

Johannes,

While I only currently read the abstract and not the full paper, I suspect
the algorithm is independent of the Bundling protocol. Is that correct?

Systems and applications within the disconnected and disjoint network may
likely want to have some notion of time for things like security
certificates, time-stamping sensor data and such. Thus, I see
time-synchronization  algorithms as quite useful independent of  the
store, carry and forward implementation.

On the other hand, I would not want my forwarding implementation to
require time-synchronization.  I believe this is what would be called a
chicken or the egg problem (I.E. circular reference).

Will