Subject: Re: [dtn-interest] problem statements

From: Kevin Fall <[email-masked]>
Date: Sat, 15 Mar 2014 12:15:27 -0400

Oh please... not the same old debate and false assertions.  You may
dispute 'intentionally', but you would be wrong.

Go ahead and read the e2e paper.  It is in fact what drove the design
wrt error control.  In particular:

>The answer is that threat number four may have been eliminated, but the careful file transfer application must still >counter the remaining threats, so it should still provide its own retries based on an end-to-end checksum of the file. >And if it does so, the extra effort expended in the communication system to provide a guarantee of reliable data >transmission is only reducing the frequency of retries by the file transfer application; it has no effect on inevitability or >correctness of the outcome, since correct file transmission is assured by the end-to-end checksum and retry whether >or not the data transmission system is especially reliable.

>Thus the argument: in order to achieve careful file transfer, the application program that performs the transfer must >supply a file-transfer-specific, end-to-end reliability guarantee - in this case, a checksum to detect failures and a >retry/commit plan. For the data communication system to go out of its way to be extraordinarily reliable does not >reduce the burden on the application program to ensure reliability.

Also, in the 2003 DTN paper (section 4.5):

>Furthermore, the provision of the end-to-end optional acknowledgment is consistent with the end-to-end argument   >[16] ---that only the applications truly know what they require.

- Kevin

On Sat, Mar 15, 2014 at 8:27 AM,  <[email-masked]> wrote:
> 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
>
> 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
>>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: <[email-masked]>
Date: Sat, 15 Mar 2014 23:35:06 +0000

as has been said many times before, there are two dimensions to reliable delivery
getting there (in a timely fashion) preventing erasures
getting the right stuff there (and knowing it's not wrong) - preventing errors

the 2003 sigcomm paper discusses the first (and custody transfer helps
with timeliness by limiting the scope of resends - often like proxying,
sometimes like local ARQ resends).
That handles packet loss and resends. that's where the focus
of the sigcomm paper is.

the sigcomm paper does not discuss the second. the E2E paper specifically
concerns itself with error checking and checksums, no mention of those in the
sigcomm paper. The importance of checksums wasn't understood; the
importance of delivery was.

But the sigcomm paper's emphasis on security
gives errorchecking as an unconsidered sideeffect of a heavyweight
security design, to guard against errors, first guard against attacks.
And security needed timesync, so there's that.

Lloyd Wood
http://sat-net.com/L.Wood/dtn
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Kevin Fall [[email-masked]]
Sent: 15 March 2014 16:15
To: Wood L  Dr (Electronic Eng)
Cc: [email-masked]
Subject: Re: [dtn-interest] problem statements

- Kevin