[Ndn-interest] Time and synchronization

[Alex Afanasyev]

> On Feb 5, 2015, at 1:50 PM, Chaim Rieger <chaim.rieger at gmail.com> wrote:
> 
> Signed PGP part
> So to answer half of my own question based on further reading and
> input from you.
> 
> NDN does not maintain any form of synchronization with Time (which is
> an external algorithm). NDN will however upon the establishment of a
> session carry a sync (packet?) between the producer and the recipient,
> and any further packets within said session window will be
> incremented, thereby verifying that all data is synchronized.

Any synchronization is applications specific.  If some application needs it, then it may require (either as part of documentation or do something about it).  There is nothing that is specific to the networking architecture itself.  Also, there is nothing that prevents you to implement such sessions, you may just lose some benefits of NDN network.

One potential issue with "sessions" is that there is no guarantee that NDN will deliver subsequent interests to the same place.  NDN is data oriented architecture.  Interest is trying to discover where data is located (using routing and other information as an input).

--
Alex

> Is this statement somewhat correct. Am trying to put into as simple
> terms as possible for easy understanding by non technical folks.
> 
> 
> 
> 
> On 2/5/2015 1:45 PM, Alex Afanasyev wrote:
> >
> >> On Feb 5, 2015, at 1:18 PM, <Marc.Mosko at parc.com>
> >> <Marc.Mosko at parc.com> wrote:
> >>
> >> The NDN spec for signed interests specifically says "Note that
> >> this verification process require signed interest to be received
> >> in order. Applications adopting this process may want to take
> >> 'stop-and-wait' strategy.”  Therefore, the actual
> >> synchronization of timestamps is not essential, they are just a
> >> non-monotonic increasing sequence number.  This may or may not
> >> work for you application.
> >>
> >> Computing the grace interval, as specified there, does require
> >> at least loose synchronization of clocks.
> >>
> >>> Note that for the first Interest, the state is not available.
> >>> To handle this special situation, the recipient should check
> >>> the Interest's timestamp against a grace interval (e.g., 120
> >>> seconds) [current_timestamp - interval/2, current_timestamp +
> >>> interval/2]. The first interest is invalid if its timestamp is
> >>> outside of the interval.
> >>
> >>
> >> DTLS and IPsec use a sliding window, so they specifically
> >> protect against replay without enforcing ordered packet arrivals.
> >> They use sequence numbers, not timestamps.
> >
> > The reason they can use sequence numbers is because the "session"
> > is getting authorized in the beginning with some challenge/nonce.
> > We probably can do something similar, but idea was to avoid any
> > sessions that need to be established before performing the
> > control.
> >
> > -- Alex
> >
> >>
> >> Marc
> >>
> >> On Feb 5, 2015, at 1:05 PM, Chaim Rieger
> >> <chaim.rieger at gmail.com> wrote:
> >>
> > Followup After reading
> > http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing
> >
> >
> >
> Snip...
> >
> > valid signed Interest whose timestamp is equal or later than the
> > timestamp of the received one has been received before. Note that
> > in order to detect this situation, the recipient needs to maintain
> > a latest timestamp state for each trusted public key
> >
> >
> > This speaks to my question, NDN has some requirements that depend
> > on Time/Timestamp. Who is the master of said Time ? If I were to
> > generate data in the future (Time+60s) would that be read after
> > data that is generated in RealTime 30 Seconds from now ?
> >
> >
> > There seems to have been some minor discussion that broached this
> > subject on this mailing list back in Sept of 2014. Does my
> > question(s) make sense ?
> >
> >
> >
> > On 2/5/2015 12:36 PM, Junxiao Shi wrote:
> >>>>> Hi Chaim
> >>>>>
> >>>>> There isn't a timestamp on Data packet at network layer.
> >>>>> If your application needs it, add a timestamp at
> >>>>> application layer as part of Content.
> >>>>>
> >>>>> Yours, Junxiao On Feb 5, 2015 12:32 PM, "Chaim Rieger"
> >>>>> <chaim.rieger at gmail.com> wrote:
> >>>>>
> >>>>> When generating data that is for multicasting/distribution
> >>>>> on an interactive level how would ndn keep track of the
> >>>>> time across the network. Data has a requirement to be
> >>>>> delivered and interacted with at a certain time after
> >>>>> which it should expire or be ignored. Is there some sort
> >>>>> of timekeeping within the NDN protocol ?
> >>>>>> _______________________________________________
> >>>>>> Ndn-interest mailing list Ndn-interest at lists.cs.ucla.edu
> >>>>>>
> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> >>>>>>
> >>>>>
> >
> >>>>>>
> >>>>>>
> >>> _______________________________________________ Ndn-interest
> >>> mailing list Ndn-interest at lists.cs.ucla.edu
> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> >>
> >>
> >> _______________________________________________ Ndn-interest
> >> mailing list Ndn-interest at lists.cs.ucla.edu
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> >
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150205/2f3e68ab/attachment.bin>