[Ndn-interest] any comments on naming convention?

[Dave Oran (oran)]

On Sep 16, 2014, at 9:56 AM, Massimo Gallo <massimo.gallo at alcatel-lucent.com> wrote:

> 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?
> 
Because Names are a multi-layer data structure.
We don’t have naming tunnels, or other encapsulations in NDN.

Also, history has shown that unless one goes to extreme lengths to opacify things (e.g. through encryption), lower layer implementations will inevitably “peek” and possibly “poke” at the supposedly higher layer data structures and conventions. We’ve seen this with port numbers and lots of other “higher layer” constructs in the IP world.

Therefore, it seems prudent to design the system such that the inevitable attempts by L3 to exploit L4+ stuff have less chance of breaking things. That’s why I advocate ensuring the L3 does not have to look at typed name components to work right, but that we not strictly layer naming conventions in such a way that we create aliasing problems, or robustness problems when the L3 guys do their “peeking”.

DaveO.

> 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
>> 
>> 
>