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

Alex Afanasyev alexander.afanasyev at ucla.edu
Wed Jul 23 17:32:03 PDT 2014 

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

On Jul 21, 2014, at 7:10 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> Please take a look at the updated memo: http://redmine.named-data.net/attachments/download/102/convention.pdf
> 
> I tried to address these and some other questions that we have discussed during NFD call today.
> 
> As for FinalBlockId I don't see how it is relevant to the naming conventions document.  For me, it is directly related to segmentation (and may be other) protocol(s), which deserve its(their) own memo(s).   In the naming convention we just defined how to represent segmenting, but not how the whole protocol works.  Also, as we discussed long ago, FinalBlockId is not the only (not the best either) way to implement segmentation...
> 
> ---
> Alex
> 
> 
> On Jul 20, 2014, at 10:37 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
>> 
>> 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
>>>>> 
>>>> 
>>> 
>> 
>

More information about the Nfd-dev mailing list