Subject: [dtn] DTN Epoch

From: Marco Kaulea <[email-masked]>
Date: Wed, 11 Apr 2018 18:01:50 +0200

Hello,
I'm currently working through the current bpbis draft and
will comment on it should I notice anything.
But one topic I would like some clarification on before I
go on.
In chapter 4.1.6 DTN Time is defined as seconds since
the start of 2000 in the "UTC scale". This would as far
as I understand include leap seconds.

Is my understanding correct?
Is there an easy way to get this value on a normal linux
system? Unix timestamps seem to ignore leap seconds.

Regards
Marco

---

From: Marco Kaulea <[email-masked]>
Date: Fri, 13 Apr 2018 14:39:21 +0200

Hello Scott,

At least Linux mentions that that the result from time() function does
not contain leap seconds [0].
Most likely because because Unixtime itself does not contain leap seconds.

At the moment this would lead to DTN-Time being 5 seconds behind UTC
at the moment. For most
deployment such a difference would probably be irrelevant, but since
the lifetime is specified in
microseconds some applications might expect fast responses.
This offset will probably continue to grow, considering there only
have been positive leap seconds
up to this point.

Most implementations probably wont care, but it could become a gotcha
when connecting
systems that handle this differently.

Marco

On Fri, Apr 13, 2018 at 1:45 PM, Burleigh, Scott C (312B)
<[email-masked]> wrote:
> Hi, Marco.  I think we always assume that the time() and gettimeofday() functions return the correct UTC time including leap seconds on virtually all platforms.  That may not be true, but absolute accuracy is less important than alignment with other nodes' understanding of the current time, and in practice DTN timing requirements are not so tight that a small number of seconds error one way or another will make any difference.

[0] http://man7.org/linux/man-pages/man2/time.2.html#NOTES
[1] https://en.wikipedia.org/wiki/Unix_time

---

From: William Ivancic <[email-masked]>
Date: Fri, 13 Apr 2018 08:56:16 -0400

Timing items such as this will continue as long as absolute time is required.  But, alas, this has been debated since at least the early 2000s.  If you're really concerned, investigate the DTNRG email archives.

Will

On 4/13/18, 8:40 AM, "dtn on behalf of Marco Kaulea" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Scott,

    
    
    Marco

    
    _______________________________________________
    dtn mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dtn

---

From: Rick Taylor <[email-masked]>
Date: Fri, 13 Apr 2018 13:28:37 +0000

Is the pragmatic solution to avoid referring to UTC when discussing
absolute time, and perhaps use TAI with time(), rather than getting
caught up in leap-seconds and localtime().  This pushes the onus onto
the implementation rather than the specification.

Maybe some text like "Number of seconds from 1970-01-01 00:00:00 TAI"?

As I understand it, nodes just need to know an absolute 'when', it
doesn't have to correlate to anything us humans understand as 'now'. 

Rick

On Fri, 2018-04-13 at 08:56 -0400, William Ivancic wrote:
> Timing items such as this will continue as long as absolute time is
> required.  But, alas, this has been debated since at least the early
> 2000s.  If you're really concerned, investigate the DTNRG email
> archives.
> 
> Will
> 
> On 4/13/18, 8:40 AM, "dtn on behalf of Marco Kaulea" <dtn-bounces@ie
> tf.org on behalf of [email-masked]> wrote:
> 
>     Hello Scott,
>     
>     > Hi, Marco.  I think we always assume that the time() and
> gettimeofday() functions return the correct UTC time including leap
> seconds on virtually all platforms.  That may not be true, but
> absolute accuracy is less important than alignment with other nodes'
> understanding of the current time, and in practice DTN timing
> requirements are not so tight that a small number of seconds error
> one way or another will make any difference.
>

---

From: Brian Haberman <[email-masked]>
Date: Fri, 13 Apr 2018 09:32:48 -0400

Hi Rick,

> the implementation rather than the specification.

As long as the point of reference is consistent, nodes will have the
same view of time. That is, pick UTC or TAI as the time source and
things should be fine.

Regards,
Brian

---

From: Rick Taylor <[email-masked]>
Date: Fri, 13 Apr 2018 16:03:09 +0000

Hi Brian,

> same view of time. That is, pick UTC or TAI as the time source and

From my understanding of UTC, it involves complications such as leap
seconds, whereas TAI is monotonically increasing

Cheers,

Rick

> > >     At least Linux mentions that that the result from time()
> > > function
> > > does
> > >     Most likely because because Unixtime itself does not contain
> > > leap
> > > seconds.
> > >     
> > >     At the moment this would lead to DTN-Time being 5 seconds
> > > behind
> > > UTC
> > >     at the moment. For most
> > >     deployment such a difference would probably be irrelevant,
> > > but
> > > since
> > >     Most implementations probably wont care, but it could become
> > > a
> > > gotcha
> > >     when connecting

---

From: Brian Haberman <[email-masked]>
Date: Fri, 13 Apr 2018 12:16:48 -0400

Hi Rick,

> seconds, whereas TAI is monotonically increasing

Yes, UTC involves the complications of leap seconds. But it still
provides a consistent time reference, if you are synchronizing
consistently across the platforms of interest.

While leap second support varies across Unix/Linux distributions, there
are tools to manage the occurrences of leap seconds so that your
distribution has the correct UTC.

So, my point was aimed at the last sentence in your response. You can
push the onus onto the implementation to figure out what tools are
needed to make UTC work.

Just my $0.02,
Brian

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 13 Apr 2018 16:19:05 +0000

I would propose that we simply agree on "unix epoch time", which is what Linux time functions return.  Let's please not make this any more difficult than necessary.

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Rick Taylor
Sent: Friday, April 13, 2018 9:03 AM
To: [email-masked]; [email-masked]
Subject: Re: [dtn] DTN Epoch

Hi Brian,

On Fri, 2018-04-13 at 09:32 -0400, Brian Haberman wrote:
> > caught up in leap-seconds and localtime().  This pushes the onus 
> > onto the implementation rather than the specification.
> > 
> 

From my understanding of UTC, it involves complications such as leap seconds, whereas TAI is monotonically increasing

Cheers,

Rick

> > > Timing items such as this will continue as long as absolute time 
> > > is required.  But, alas, this has been debated since at least the 
> > > early 2000s.  If you're really concerned, investigate the DTNRG 
> > > email archives.
> > > 
> > > Will
> > > 
> > > On 4/13/18, 8:40 AM, "dtn on behalf of Marco Kaulea" <dtn-bounce 
> > > s@ie tf.org on behalf of [email-masked]> wrote:
> > > 
> > >     Hello Scott,
> > >     
> > > function does
> > > leap seconds.
> > > behind UTC
> > > gettimeofday() functions return the correct UTC time including 
> > > leap seconds on virtually all platforms.  That may not be true, 
> > > but absolute accuracy is less important than alignment with other 
> > > nodes'

---

From: Marco Kaulea <[email-masked]>
Date: Fri, 13 Apr 2018 19:15:26 +0200

Hello everyone,

I'm sorry to have caused this discussion, I didn't know that some of
this was already discussed in the dtnrg.
The only point I wanted to bring up, was that unixtime does not
include leap seconds and DTN Time referring
to UTC would need to. Defining it in terms of unix epoch time would
probably work well.

Marco

[0] https://www.ietf.org/mail-archive/web/dtn-interest/current/msg01895.html
[1] https://www.ietf.org/mail-archive/web/dtn-interest/current/msg00571.html

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 13 Apr 2018 17:01:07 -0400

Hi,

Would NTP time be the same as “unixtime” or “unix epoch time”
as intended in the various notes below ?  

(My guess is that they are the same, but I am not well informed
if the NTP specification changed when it went from RFC-1305
to RFC-5905. :-)

If yes, perhaps cite the NTP (RFC-5905) in the DTN documents
and define time in the DTN documents in terms of the NTP RFC cited ??

Cheers,

Ran

> On Apr 13, 2018, at 13:15, Marco Kaulea <[email-masked]> wrote:
> 
> Hello everyone,
>

---

From: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]>
Date: Sun, 15 Apr 2018 02:50:26 +0000

I do think defining the base as the UNIX epoch would be good as well.

I'll note that there is also a discrepancy between the units of the bundle age block (seconds) and the units of the lifetime (microseconds).  My expectation would be for those two units to agree with one another - is there a reason that they don't?

-Gilbert

The above reflects my personal opinion, and should therefore not be construed to represent an official position of either NASA or the US Government.
________________________________________
From: dtn [[email-masked]] on behalf of Marco Kaulea [[email-masked]]
Sent: Friday, April 13, 2018 1:15 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]
Cc: [email-masked]; [email-masked]; Rick Taylor
Subject: Re: [dtn] DTN Epoch

Hello everyone,

Marco

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 20 Apr 2018 03:13:18 +0000

As I recall, it was requested in DTN WG that lifetime in bpbis be expressed in microseconds for better control over high-speed traffic in low-delay environments.  You are right, the bundle age field in the bundle age block should be modified in the same way.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
Sent: Saturday, April 14, 2018 7:50 PM
To: Marco Kaulea <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]; Rick Taylor <[email-masked]>; [email-masked]
Subject: Re: [dtn] DTN Epoch

-Gilbert

Hello everyone,

I'm sorry to have caused this discussion, I didn't know that some of this was already discussed in the dtnrg.
The only point I wanted to bring up, was that unixtime does not include leap seconds and DTN Time referring to UTC would need to. Defining it in terms of unix epoch time would probably work well.

Marco

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 20 Apr 2018 04:48:07 +0000 (UTC)

high speed traffic in low-delay environments is pretty muchthe definition of what delay-tolerant networking is not about.
Still, a nice illustration of use cases, and not being ableto satisfy all use cases. Lloyd Woodhttp://sat-net.com/L.Wood/dtn/

      From: "Burleigh, Scott C (312B)" <[email-masked]>
 To: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]>; Marco Kaulea <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]>; Rick Taylor <[email-masked]>
 Sent: Friday, 20 April 2018, 13:13
 Subject: Re: [dtn] DTN Epoch

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
Sent: Saturday, April 14, 2018 7:50 PM
To: Marco Kaulea <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]; Rick Taylor <[email-masked]>; [email-masked]
Subject: Re: [dtn] DTN Epoch

-Gilbert

Hello everyone,

Marco

---

From: <[email-masked]>
Date: Fri, 20 Apr 2018 05:37:35 +0000

Lloyd,
Off the top of my head, I can think of several applications where the delay and throughput are wildly variable, all of which are (or should be) perfect use-cases for DTN. For example (and expressed in list format, in order to minimize the required attention span):

·         Cellular-based applications, conveyed over long distances (LTE/3G/2G/No connectivity): Assuming that there’s connectivity, the delays should remain under 1 second. However, the total throughput will change in orders of magnitude.

·         Mesh networking: Assuming optimal connectivity, the throughput may be extremely high, although those periods may be brief and ill-defined. Separately, the throughput between adjacent nodes may also be non-trivial, but the E2E delay would be high.

·         For the space folks: optical comms: High-throughput, high potential for occlusion. May be combined with lower-performance links (which may also have multiple hops). This is basically an apex of high-speed/theoretically-low-delay traffic.

BP/BPBis are robust-enough protocols to satisfy these use-cases, so why shouldn’t we entertain the thought that they may be used as such? Arbitrary decisions of what delay-tolerant networking is “about” are useless, unless they’re backed up with some evidence. Some of my work is based around occasionally-challenged networking, and BP is an excellent mechanism for such things.

Thanks,
Jeremy

From: dtn [mailto:[email-masked]] On Behalf Of Lloyd Wood
Sent: Freitag, 20. April 2018 06:48
To: Burleigh, Scott C (312B); Clark, Gilbert J. (GRC-LCA0); Marco Kaulea
Cc: [email-masked]; Rick Taylor; [email-masked]
Subject: Re: [dtn] DTN Epoch

high speed traffic in low-delay environments is pretty much
the definition of what delay-tolerant networking is not about.

Still, a nice illustration of use cases, and not being able
to satisfy all use cases.

Lloyd Wood
http://sat-net.com/L.Wood/dtn/

________________________________
From: "Burleigh, Scott C (312B)" <[email-masked]<mailto:[email-masked]>>
To: "Clark, Gilbert J. (GRC-LCA0)" <[email-masked]<mailto:[email-masked]>>; Marco Kaulea <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Rick Taylor <[email-masked]<mailto:[email-masked]>>
Sent: Friday, 20 April 2018, 13:13
Subject: Re: [dtn] DTN Epoch

Scott

-----Original Message-----
From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
Sent: Saturday, April 14, 2018 7:50 PM
To: Marco Kaulea <[email-masked]<mailto:[email-masked]>>; Burleigh, Scott C (312B) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Rick Taylor <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dtn] DTN Epoch

-Gilbert

The above reflects my personal opinion, and should therefore not be construed to represent an official position of either NASA or the US Government.
________________________________________
From: dtn [[email-masked]<mailto:[email-masked]>] on behalf of Marco Kaulea [[email-masked]<mailto:[email-masked]>]
Sent: Friday, April 13, 2018 1:15 PM
To: Burleigh, Scott C (JPL-312B)[Jet Propulsion Laboratory]
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Rick Taylor
Subject: Re: [dtn] DTN Epoch

Hello everyone,

Marco

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

_______________________________________________
dtn mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dtn

---

From: Lloyd Wood <[email-masked]>
Date: Sat, 21 Apr 2018 03:12:44 +0000 (UTC)

Jeremy,

there's a graphical taxonomy in Fig 1 of 
http://dx.doi.org/10.1109/ICUMT.2009.5345655Sharing the dream: the consensual hallucination offered by the Bundle Protocol.

your cellular and mesh examples? at the bottom, along the unexpected-interruption disruption-tolerant axis - and pretty much in the Internet cloud at bottom right of that figure.
space folk (delivery from probes) - occlusion is scheduled and planned for, that's a different model and delay-tolerant.

The use case matters, because as path delay decreases, network nodes can share state and share fate; e.g. synchronous communications, remote procedure calls become more useful, real-time transactions can be done across the path between nodes.

As delay increases, nodes move from being able to use those techniques to having relying more on buffered storage.
As disruption increases, dealing with fragmentation of data delivery (reactive rather than scheduled proactive) matters more.
The scenario leads to design choices that benefit the use in the scenario.

Too large a problem space means too large a set of problems to address; to design for everything is to design for nothing.
'delay under one second' isn't a perfect use case, it's just really easy to address by a large number of solutions - including ones that aren't the bundle protocol, and which offer more than the bundle protocol does for that scenario. robustness is in the eye of the beholder.

And if you claim to have multiple perfect use cases, you misunderstand the meaning of 'perfect'. 

regards

Lloyd Wood
http://sat-net.com/L.Wood/dtn

my attention has been on DTN for over a decade. 'tedium-tolerant networking' has a nice ring to it.

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked]; [email-masked]; [email-masked]; [email-masked] 
Cc: [email-masked]; [email-masked]; [email-masked]
Sent: Friday, 20 April 2018, 17:23
Subject: Re: [dtn] DTN Epoch

Lloyd,

Thanks,
Jeremy  
 
From:dtn [mailto:[email-masked]] On Behalf Of Lloyd Wood

 
Lloyd Wood

From:"Burleigh, Scott C (312B)" <[email-masked]>

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
Sent: Saturday, April 14, 2018 7:50 PM
To: Marco Kaulea <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]; Rick Taylor <[email-masked]>; [email-masked]
Subject: Re: [dtn] DTN Epoch

-Gilbert

Hello everyone,

Marco

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 26 Apr 2018 00:21:04 +0000 (UTC)

I received some feedback on pointing to a paywall, and the other url hint wasn't sufficient.

The paper I mentioned is freely available at

http://personal.ee.surrey.ac.uk/Personal/L.Wood/dtn/bundle.html 

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/index.html#e-dtn-position (just above A Bundle of Problems)

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/e-dtn-oct-2009-wood-position-paper.pdf  (see fig 1)

http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/e-dtn-oct-2009-psaras-position-slides.pdf (see page 4)

https://www.researchgate.net/publication/221003862_Sharing_the_dream_the_consensual_hallucination_offered_by_the_Bundle_Protocol 

https://www.academia.edu/918617/Sharing_the_dream_The_consensual_networking_hallucination_offered_by_the_Bundle_Protocol 

Lloyd Wood

________________________________
From: Lloyd Wood <[email-masked]>
To: "[email-masked]" <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>
Sent: Saturday, 21 April 2018, 13:12
Subject: Re: [dtn] DTN Epoch

Jeremy,

http://dx.doi.org/10.1109/ICUMT.2009.5345655

Sharing the dream: the consensual hallucination offered by the Bundle Protocol.
your cellular and mesh examples? at the bottom, along the unexpected-interruption disruption-tolerant axis - and pretty much in the Internet cloud at bottom right of that figure.
space folk (delivery from probes) - occlusion is scheduled and planned for, that's a different model and delay-tolerant.

regards

Lloyd Wood

Lloyd,

Thanks,
Jeremy  

Lloyd Wood

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
Sent: Saturday, April 14, 2018 7:50 PM
To: Marco Kaulea <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]; Rick Taylor <[email-masked]>; [email-masked]
Subject: Re: [dtn] DTN Epoch

-Gilbert

Hello everyone,

Marco

---

From: William Ivancic <[email-masked]>
Date: Thu, 26 Apr 2018 08:20:08 -0400

What happens when you have no requirements document and no problem statement to bound your solution space?  2018 and still working on a solution.

-- Will

On 4/25/18, 8:22 PM, "dtn on behalf of Lloyd Wood" <[email-masked] on behalf of [email-masked]> wrote:

    

    

     
    
    Lloyd Wood

    
    Jeremy,

    

    

    regards
    
    Lloyd Wood

    
    Lloyd,

    Thanks,
    Jeremy  

    
    
    Lloyd Wood

    
    
    Scott
    
    -----Original Message-----
    From: dtn <[email-masked]> On Behalf Of Clark, Gilbert J. (GRC-LCA0)
    Sent: Saturday, April 14, 2018 7:50 PM
    To: Marco Kaulea <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
    Cc: [email-masked]; Rick Taylor <[email-masked]>; [email-masked]
    Subject: Re: [dtn] DTN Epoch

    
    -Gilbert

    Hello everyone,

    Marco