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

Sun Jul 20 22:37:05 PDT 2014

Thanks.  Could you clarify the semantics of the proposed conventions a bit
further? For example:

"Segmenting is used when the application wants to cut a large data into
small pieces"

=> Are the individual segments not really usable on their own, or is this
irrelevant to the convention?

"Versioning is necessary if the application wants to update previously
published data and publish again under the same name."

=> Would our current use of versions as frame timestamps make sense?  If
so, there may be a way to phrase this more inclusively than just talked
about updating previously published data... If not, perhaps we do want a
timestamp convention...

=> What about non-time-based versioning?

"While the sequence number value in these collections is syntactically
similar to sequence-based segmentation, the sequence number has a very
different meaning."

=> What is that meaning?  (This is the one I'm least clear on.  There is
an implicit definition of sequence but it's probably best to make it
explicit... monotonically increasing non-negative integer?)

As I mentioned in a previous email, perhaps the specific role of
FinalBlockID in each case should be explained?

Jeff

On 7/20/14, 6:46 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu> wrote:

>Please check the first draft for the naming conventions memo
>(http://redmine.named-data.net/attachments/download/100/convention.pdf
>or  git at git.irl.cs.ucla.edu:papers/ndn-memos-naming-conventions.git)
>
>The primary intention for the document is to just define the encoding
>format and several (4 to be exact) markers.  In future we may include
>more discussions, motivations, and examples.
>
>---
>Alex
>
>On Jul 20, 2014, at 8:01 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
>> 
>> Hi,
>> 
>> As I mentioned before, I think this is a really useful conversation.
>> 
>> I'd suggest that conventions be captured and proposed in a spec document
>> rather than by email, so that there can be examples / motivations and a
>> little deeper discussion.  I think this is also a good way to share the
>> results of the dialogue.
>> 
>> For example, it may also be necessary (and interesting) to define a
>> convention for the FinalBlockId depending on whether something is a
>> sequence or a segment, if we indeed make that distinction. (As an
>>aside, I
>> notice that the tlv 0.2 spec still shows "NumberComponent" as a
>>potential
>> type for FinalBlockID.  From talking with Lixia, I thought that we have
>> decided that there will not be typed components in the architecture.  If
>> that is true, then all such references should be removed.  If not, this
>> should be discussed, too.)
>> 
>> Some thoughts below in addition to the ones sent earlier.
>> 
>> 
>>>> 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.
>> 
>> Yes, this makes sense to me.  And then FinalBlockID indicates the end
>> segment if known?
>> 
>>>> 
>>>> - "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.  
>> 
>> So is the idea that individual segments are not useful, but sequence
>> elements are?  Or that segments *could* be useful on their own, but the
>> application does not declare them that way?
>> 
>> Another useful thing here would be whether ordering matters - sequence
>> implies ordering, perhaps we need a notion of an unordered collection?
>> Would be nice to perhaps sketch out a paper with these conventions and
>> elaborate on them and potential use cases.
>> 
>>>> 
>>>> 
>>>> 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.
>> 
>> 
>> How is "semantically correct" defined?  Maybe we need use cases to be
>> discussed? 
>> 
>> 
>> Thanks,
>> Jeff
>> 
>> 
>>>> 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
>>> 
>> 
>