[Nfd-dev] Naming conventions for "sequence number"

Alex Afanasyev alexander.afanasyev at ucla.edu
Thu Jul 24 15:38:25 PDT 2014


On Jul 24, 2014, at 10:06 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

> Hi Alex and all,
> 
> Some comments from me and Giulio.
> 
> Segmentation: looks good to us.
> 
> Versioning: must the version really correspond to the number of
> millisecs since epoch? I can see a couple of problems with this:
>    1/ millisecs granularity may not be enough for the application
>    2/ if accurate clock synchronization is indeed a problem, using
> timestamps is pointless, but on the other hand there's no defined
> marker for non-time-based versioning, so what do we do?
> 
> Maybe the value for the version marker should be defined more broadly
> as a monotonically increasing nonnegative integer (but not necessarily
> sequential), leaving the door open to more use cases. On the other
> hand, one could argue that this new definition isn't much different
> from a sequence number (it only lacks the sequentiality property),
> therefore maybe we could merge versioning into sequencing. If needed,
> applications can still use timestamps in name components, but those
> components simply won't be marked in any special way.

Hi Davide and Giulio. Thanks for the comments!

The reason I'm tempted to keep the current definition of versioning is a little bit to do with application inter-operability in mind.  If version is defined as increasing number, then there is no clear definition of how distributed production of data can be implemented.  If producers perform some way of version synchronization, then only these producers will be able to produce the "correct" version, while third-parties will be excluded and not able to produce never version of the data (this is kind of a vague argument, but I think there could be use cases for that).  Giving a flawed, but simple mechanism to generate "correct" time-based version is in this sense better.

As for dealing with applications that needs better granularity...  In some cases it is possible to cheat, ensuring that "version" is increased at least by one for the next generated data.  For other cases we definitely need to define some marker or some other way to give reasonable understanding for others about the component.

> Conversely, if the majority prefers keeping the proposed timestamp
> semantics, can we at least call it "timestamping" instead of
> versioning?

This what Lan was proposing before.  Completely replacing versioning with timestamping doesn't make sense for me.  Probably, we can have such a convention, though it should be used just for "timestamping" purposes, which not necessarily the same as versioning.  Also, if convention for timestamping is defined, we need to specify/exemplify how this could be used (e.g., by third-parties).

---
Alex


> Thanks,
> Davide
> 
> On Thu, Jul 24, 2014 at 2:32 AM, Alex Afanasyev
> <alexander.afanasyev at ucla.edu> wrote:
>> Hi guys,
>> 
>> We need to have an approval for the naming convention spec before we can proceed with changes to the libraries.  Given the testbed deployment is scheduled this Friday, the spec (at least on conceptual level, we can correct wordings later) needs to be approved before that
>> 
>> Just in case, link to the latest version: http://redmine.named-data.net/attachments/download/102/convention.pdf
>> 
>> ---
>> Alex
>> 





More information about the Nfd-dev mailing list