Re: [dtn-interest] Bad Clock Vs. Clock rating (0)

<> Tue, 17 May 2016 01:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B36712D57F for <>; Mon, 16 May 2016 18:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rc-zCwpyUznV for <>; Mon, 16 May 2016 18:40:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3EB112B018 for <>; Mon, 16 May 2016 18:40:17 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 17 May 2016 03:40:12 +0200
Received: from ([fe80::d198:77e5:d411:fccd]) by ([::1]) with mapi id 14.03.0294.000; Tue, 17 May 2016 03:40:13 +0200
From: <>
To: <>, <>
Thread-Topic: [dtn-interest] Bad Clock Vs. Clock rating (0)
Thread-Index: AQHRqzqu3OZs20jKEky5TB6ZR2htYp+6q5KAgAGBUwCAAAyjAIAAJ5Bg
Date: Tue, 17 May 2016 01:40:13 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_EE2A78428975E541A99B025DABBAEDF90141C0E1DLREXMBX01intra_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [dtn-interest] Bad Clock Vs. Clock rating (0)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 May 2016 01:40:21 -0000

Lloyd, I’m going to attempt to correlate your previous two emails into a single coherent view, albeit with a limited scope. Please let me know if I fail, though I’m sure you will.

RFC5050Bis includes a bundle age block which alleviates the “strict” clocking requirements (30 seconds). From your view, is this insufficient? This block handles the cases mentioned by Kevin where some nodes have accurate clocks (and set the bundle creation timestamp) and some do not (and nullify the creation timestamp but keep a bundle age block).


From: dtn-interest [] On Behalf Of Kevin Fall
Sent: Dienstag, 17. Mai 2016 03:09
Cc:;; DTN interest
Subject: Re: [dtn-interest] Bad Clock Vs. Clock rating (0)

Ah, rehashing old arguments.  A real blast from the past.

The particular paper referenced below indeed points out operational cases in which the authors had difficulty in establishing synchronized clocks.  While there are cases in which establishing time synch may be challenging, it isn't really fundamental to the design, and there are a number of other options people have implemented since then if you are faced with that problem.  (or, the more realistic/interesting case in which some nodes have a correct notion of time and others do not).  Of course, not having synchronized time causes certain features to be difficult or impossible to implement (e.g., expiring/deleting bundles that have been stored on passive media lacking actual time stamps).

The reasons for the design decision of using time synchronization was given in, for example: (, a paper from 2008.

- Kevin

On Mon, May 16, 2016 at 8:24 PM, <<>> wrote:

I was wrong, and I'd like to take this opportunity to apologise to the list for being wrong and to correct my mistake.

It was SEVEN years ago that we pointed out the fundamental problems with the bundle protocol's reliance on clocks and synchronization in our 'A Bundle of Problems' paper....

Lloyd Wood

From: dtn-interest <<>> on behalf of<> <<>>
Sent: Monday, 16 May 2016 11:25 AM

Subject: Re: [dtn-interest] Bad Clock Vs. Clock rating (0)

Five years ago we pointed out the fundamental problems with the bundle protocol's reliance on clocks and synchronization in our 'A Bundle of Problems' paper.

People are still trying to use it and work around its clocking? As Australians say: so tragic.

Lloyd Wood
From: dtn-interest <<>> on behalf of Nik Ansell <<>>
Sent: Wednesday, 11 May 2016 2:07:49 PM
Subject: Re: [dtn-interest] Bad Clock Vs. Clock rating (0)

A good way to get in touch with the IBR-DTN guys is to use the mailing list below.<>

The main admin page for the mailing list is here:

Kind Regards,

On Tue, May 10, 2016 at 11:00 PM, <<>> wrote:
Send dtn-interest mailing list submissions to<>

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to<>

You can reach the person managing the list at<>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dtn-interest digest..."

Today's Topics:

   1. Re: Bad Clock Vs. Clock rating (0) (Joerg Ott)

---------- Forwarded message ----------
From: Joerg Ott <<>>
To: Shyam B <<>>,<>
Date: Tue, 10 May 2016 07:19:16 +0200
Subject: Re: [dtn-interest] Bad Clock Vs. Clock rating (0)
I wo¨ld ask the IBR-DTN folks...

On 10.05.16 01:37, Shyam B wrote:
Hello All,

Thanks for the evolving community of DTN. I hope someone can help me
with the questions below:

How to remove time synchronization between nodes on later versions of
We are using the latest version(s) of IBRDTN on OpenWRT. I read from the
change log "Version 1.0.1 (2015-02-24)" that BAD CLOCK has been replaced
by something called clock rating (set to 0).

1) I would like to know where and how can I set this clock rating to 0
on a node? Is it to be set in the "ibrdtn.conf" file or somewhere else -
any specifics will be helpful.

2) I believe this will need to be set "on each node" and the dtnd daemon
would read this during its initiation at run-time to bypass any clock
synchronization needed to receive bundles/ as well as dtnping, am I right?

NOTE: We do not require clock synchronization to keeping our scenarios
simple. Just need a way to pass bundles between nodes "under any


Thanks for your time. Hope someone can help us soon!

Shyam, B

dtn-interest mailing list<>

dtn-interest mailing list<>