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

[Burke, Jeff]

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
>