Subject: Re: [dtn-interest] problem statements

From: Kevin Fall <[email-masked]>
Date: Thu, 13 Mar 2014 17:30:57 -0400

Part of the issue is whether the issues raised are indeed considered
to be 'problems', and in what context (operational, BP design, or
what).  The bundle protocol didn't set out to solve all the problems
one might encounter in a DTN type of environment (evidently also now
known as "DIL" -- Disconnected, Intermittent, Limited).  Perhaps most
relevant is that it didn't aim to sync clocks, didn't aim to provide
integrity on data (except within the context of the security protocol)
and didn't aim to solve the key management problem.  All of this was
(intentionally) left for further R&D and/or to other options available
from the home system [e.g., many systems have their own non-BP time
sync options and keying], but the BP made use of these things on the
assumption (reasonable for many systems) they would be available.  You
will find these discussions back several years through the archives.

I would suggest that it might be worth pursuing a couple of questions.
 There was once a discussion of 'what if some nodes don't have
synchronized time' and how to deal with that issue.  There were also
explorations of, e.g., identity based encryption as an alternative to
conventional PKI.  About the only issue from the 'problems' paper that
I accept as an actual issue is header integrity when BSP is not used.
In my opinion, that might be worth pursuing also, but seems pretty
straightforward-- likely not requiring its own 'problem statement' but
rather some agreed-upon solution.

With regards to time specifically, the timestamp was primarily there
to know when throwing old data out is ok (as opposed to guiding the
priority of forwarding).  Also, it is if anything more the case today
that most systems know the time.  And please recall that one of the
points was to be able to store data in transit outside a router..
being able to do this affects what can be assumed about how time is
handled and when throwing data out is ok (as mentioned above).

- Kevin

On Thu, Mar 13, 2014 at 1:39 PM, Templin, Fred L
<[email-masked]> wrote:
> 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
> [email-masked]
>
>> -----Original Message-----
>> From: dtn-interest [mailto:[email-masked]] On Behalf Of Johannes Morgenroth
>> Sent: Thursday, March 13, 2014 6:40 AM
>> To: [email-masked]
>> Subject: Re: [dtn-interest] Delay Tolerant Networking Time Synchronization - Problem Statement
>>
>> 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
>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: <[email-masked]>
Date: Sat, 15 Mar 2014 12:27:17 +0000

Much of that discussion was on introducing the concepts of error detection
and the end-to-end principle to a community unaware of them.

I dispute the "intentionally" - it's hard to intentionally leave out something
entirely unfamiliar, and from the early days of IPNSIG onward, I have not seen a design
document discussing and explicitly rejecting such options.

There are existing expired drafts on the time sync problem, on error detection
sans security, etc.  The group did not pursue them; they were
not viewed as important..

DTN is a set of operational requirements - difficult conditions, introducing
errors, dealing with unreliability. Designing to meet those
requirements is something we call  'engineering'. It's worth
trying.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: dtn-interest [[email-masked]] On Behalf Of Kevin Fall [[email-masked]]
Sent: 13 March 2014 21:30
To: Templin, Fred L
Cc: [email-masked]
Subject: Re: [dtn-interest] problem statements

- Kevin