[Ndn-interest] any comments on naming convention?

Massimo Gallo massimo.gallo at alcatel-lucent.com
Tue Sep 16 06:56:52 PDT 2014


Hi Dave,

Just to clarify, what i wanted to say is just said that we should 
specify name's component types if and only if layer three needs to 
understand them (e.g., segment, versioning?, ...).
What is the advantage of having components' types at layer three if it 
NEVER uses them?

Max




On 16/09/2014 15:35, Dave Oran (oran) wrote:
> On Sep 16, 2014, at 5:12 AM, Massimo Gallo <massimo.gallo at alcatel-lucent.com> wrote:
>
>> Dear all,
>>
>> Interesting discussion!
>>
>> Here are my 2 cents to the discussion.
>>
>> I think we should avoid having explicit components' type.
> Below you seem to argue pretty much the opposite.
>
>> CCN/NDN are layer three technologies that allow an end host process to retrieve some     named data. The networking layer does need only to check local cache (exact match IMO), PIT (exact match IMO) and FIB (LPM, I think we all agree on this :D!).
> I certainly wish we could agree on this change to the design, but I think it’s premature to say we all agree that LPM on the PIT and CS has proven to be highly problematic.
>
>>   The way a "consumer" requests the next in order segment is up to the transport layer as Tarek said and not a layer three functionality.
> Agree, but we’re discussing the protocol encoding, not the fetch algorithm. Names as a data structure are “shared” across multiple layers (a good thing IMO) and hence defining their semantics once as opposed to having different interpretaitons in different layers seems a good tradeoff, even it “exposes” some things to layer 3 that are not strictly necessary for layer 3 operation and could be opaque. I’ll note that the semantics and encoding of the typed name components needs to be (and is in the current proposal) done in such a way that simple byte-wise compares do the right thing for all of exact match, LPM,  and anti-aliasing.
>
>> Moreover, adding components' types may introduce problems as type explosion (also pointed by someone else in this thread).
> Type explosion is a concern, but frankly is equally a problem no matter whether typing is done by convention, markers, or types. What distinguishes the option in my opinion is resilience against aliasing, for which I think explicit typing has substantial advantages.
>
>> That said there might be some "special" components requiring conventions:
>>
>> Segment: the most important one IMO because with that field many segments can be identified as a single object and treated differently for caching purposes. (i.e. a naming convention here can be that Segment ID must be last name's component hence without an explicit segment identification)
>>
> Precisely. Which means all applications have to agree on a convention, or this needs to be “baked” into the architecture somehow. There are multiple wats to do this, but typed name components seems utterly straightforward, and can leverage the exact registration policy and machinery that is used to control all architectural constants defined by the protocol.
>
>> Versioning and Timestamp: there might be a case for explicitly identify those two components as suggested in the NDN-TR-22 but, IMO, too many naming conventions will complexify layer three operations that I would keep as simple as possible.
>>
> As long as L3 can treat these as opaque and is not required to be cognizant of name component types, their existence does not complicate L3 in any way.
>
>> Max
>>
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>
>




More information about the Ndn-interest mailing list