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

[Burke, Jeff]

Hi, 

In practice this is ambiguous: The next frame in a video is both a newer
copy of the same data (update from the camera/sensor) if you are looking
at it as "live" but also the next item in a sequence when it is a record.

I'll be able to respond to the proposal later, this is really interesting
to consider. 

Jeff


On 7/16/14, 10:21 AM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

>Hi Lan,
>
>Sequence number is not exactly a version.  A Data packet with the larger
>version should represent the same data, but just newer copy (say, two
>versions of nytimes webpage).  Sequence number is for completely
>different purposes, to represent independent Data items within a single
>data set/stream. Segments are for one data split into multiple chunks,
>e.g., for delivery purposes.
>
>My take on markers is that their primary purpose is not describe the
>specific value, rather than define semantics of the value (which also
>implies specific syntax for the value).  If we name the version just
>"timestamp", then it wouldn't really mean anything for anybody outside
>the application. One would only know that this name component hold
>timestamp, but will be able only to guess the intention of the
>application to use timestamp in this component.
>
>---
>Alex
>
>On Jul 16, 2014, at 5:10 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
>wrote:
>
>> Alex,
>> 
>> What is the difference between Version and Sequence number?  Is Version
>>based on timestamps?  If so, it seems that Version should be explicitly
>>called Timestamp.
>> 
>> Lan
>> On Jul 15, 2014, at 11:46 PM, Alex Afanasyev
>><alexander.afanasyev at ucla.edu> wrote:
>> 
>>> Hi Jeff and all,
>>> 
>>> We had a follow up discussion today about naming conventions and in
>>>particular we got to one question about "sequence numbers".   The CCNx
>>>naming convention that we going to revert for now defines markers for
>>>segments (sequential and non-sequential) and marker for version.  What
>>>this convention is missing is the marker for sequential sequence
>>>numbers for "infinite" collection.  Examples of this could be stream of
>>>generated notifications n NFD, dataset in ChronoSync, frames in webrtc
>>>(?).  In the past, we kind of used "segment" convention to represent
>>>such numbers, but during our discussion we agreed that there is
>>>different semantics for "segments" and "sequence numbers" and it is
>>>useful to explicitly distinguish between them:
>>> 
>>> - "Segment" is a Data packet that is a part of a bigger data blob
>>>(e.g., segments of one frame).  If third party (repo, cache, library?)
>>>understands this semantics, than it can try request all the segments
>>>and stop when finished.
>>> 
>>> - "Sequence number" (for "infinite" collections) denotes that the
>>>particular Data object is part of the collection, but is independent
>>>piece of this collection (individual frame).   It is also possible that
>>>such a piece can be further segmented.   If third parties understand
>>>this semantics, they can perform very different actions compared to
>>>segments.   
>>> 
>>> The proposal at hand is that we not just define markers for "segment"
>>>(%00 prefix) and "version" (%FD) as it is in NFD, but also add a new
>>>notion of sequence numbers (say, %FE for now).
>>> 
>>> This definition doesn't imply we need to do any immediate change in
>>>any of the application we have.  It is just for the future
>>>applications/updates we use a more semantically correct ways to mark
>>>out sequence numbers.  This will also prepare libraries for any
>>>convention change later.  The place where we plan to use it right away
>>>is in NFD notification stream protocol
>>>(http://redmine.named-data.net/projects/nfd/wiki/Notification).
>>> 
>>> Can you give opinions about this proposal?
>>> 
>>> ---
>>> Alex
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>