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

[Burke, Jeff]

On 7/24/14, 3:38 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>
>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.

This argument makes sense to me but is there a way we can make this work
to some arbitrary level of precision, selected by the application, rather
than requiring milliseconds.

>
>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.

I think we want to avoid this cheat if possible.  Sometimes a millisecond
is relevant, depending on what's being versioned.

> 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).

I agree - maybe just a "if you're going to use timestamps for versions,
here's how..." sort of convention?

Jeff

>
>---
>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
>>> 
>
>
>_______________________________________________
>Nfd-dev mailing list
>Nfd-dev at lists.cs.ucla.edu
>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev