[Nfd-dev] Naming conventions for "sequence number"
Burke, Jeff
jburke at remap.ucla.edu
Wed Jul 16 10:25:53 PDT 2014
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
>>
>
More information about the Nfd-dev
mailing list