Subject: [icnrg] timestamps in DTN

From: "Dirk Kutscher" <[email-masked]>
Date: Sun, 16 Jul 2017 16:02:09 +0200

As per our discussion today: the DTN bundle protocol uses absolute 
timestamps in units of seconds.

There is a creation timestamp and an additional lifetime (expiration) 
timestamp:

https://tools.ietf.org/html/draft-ietf-dtn-bpbis-07#page-17

Dirk

---

From: "David Oran" <[email-masked]>
Date: Sun, 16 Jul 2017 16:12:35 +0200

More opinion:

1. Absolute time works better than relative time in protocols. I stand 
by that.
2. In ICN protocols it makes perfect sense to make creation time part of 
the name rather than (or in addition to) as an independent field.
3. I think it is inconvenient at a minimum, and highly messy for 
applications if you try to put expiration time as part of the name. 
It’s quite reasonable for the consumer part of an application to be 
able to guess creation times (especially realtime applications running 
on isochronous or synchronous clocks). But it seems really hard to guess 
expiration times, because those depend on things like jitter buffers and 
playout point offsets.
4. Relative times for cache controls are hard to make work right. 
(Personal experience)

DaveO

On 16 Jul 2017, at 16:02, Dirk Kutscher wrote:

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

---

From: Joerg Ott <[email-masked]>
Date: Mon, 17 Jul 2017 09:01:04 +0200

Some more bits of lessons learned from DTN:

Absolute time works wonderfully if your nodes are well connected and
have access to a time source (via NTP, GPS, or whatever).  But it
turns out to be problematic if you don't have a common frame of
reference, like in disconnected or opportunistic settings.  Given
the number of (research) papers I have seen applying ICN to this
space, this is probably worth a thought.

Whenever expiry times are short relative to potential clock mismatch
absolute time may also get somewhat messy.  I am not saying that
relative times are easier to manage, but it is worthwhile keeping this
in mind, too.

Jörg

On 16.07.17 16:12, David Oran wrote:
>  2. In ICN protocols it makes perfect sense to make creation time part
>     of the name rather than (or in addition to) as an independent field.
>     able to guess creation times (especially realtime applications
>     running on isochronous or synchronous clocks). But it seems really
>     hard to guess expiration times, because those depend on things like
>     jitter buffers and playout point offsets.
>     There is a creation timestamp and an additional lifetime
>     (expiration) timestamp:
>

---

From: "David Oran" <[email-masked]>
Date: Mon, 17 Jul 2017 12:20:35 +0200

DaveO

> space, this is probably worth a thought.
I agree. In the limit cases the problem is quite challenging no matter 
whatever clocking scheme you pick. I’d need to be convinced that 
relative clocks in practice make these cases any easier. I think they 
just introduce slightly different failure semantics (like data living 
longer than you would like, since relative clocks do not deal with 
queueing or propagation delay of packets) but are otherwise inferior.

> absolute time may also get somewhat messy.
No disagreement there. We have to choose our poison, and I argue that 
absolute clocks are less toxic, ESPECIALLY in cases where there are 
caches.

> I am not saying that

---

From: Joerg Ott <[email-masked]>
Date: Mon, 17 Jul 2017 13:43:01 +0200

No disagreement, but see inline.

Jörg

> queueing or propagation delay of packets) but are otherwise inferior.

We discussed doing ingress timestamping incoming bundles and updating
them to reflect queuing delay.

> absolute clocks are less toxic, ESPECIALLY in cases where there are caches.

Indeed.  Having done a review demo recently with a a bunch of systems
in the same room (including Raspberry Pis who don't update their clocks
when powered off), dealing with somewhat short lifetimes makes such
setups quite a bit of a game.