[Ndn-interest] How is scalability done globally given current name structure

[Andrea Detti]

On 01/17/2015 04:15 AM, Chaim Rieger wrote:
> On 1/16/2015 1:16 AM, Andrea Detti wrote:
>> Dear Kuo,
>> this seems to me  again the plain old scalability problem of NDN/CCN
>> that I (re)-observed in the mailing list some days ago (see my mails
>> or Locator hints, updated cisco packet format draft).
>>
>> I proposed the introduction of a ContentLocator TLV field (aka locator
>> hint, routing info, forwarding alias, etc. ) which contains a set of
>> names used to help routing in those contexts where pure routing by
>> object name practically does not scale. ContentLocator is used by an
>> NDN/CCN router when FIB is unable to forward on (Object) name.
>>
>> Thus in your case the Interest fields would be:
>>
>> (Object) Name : Foo
>> ContentLocator : {ndn/tw/sinica/Foo;  ndn/edu/ucla/Foo}
>>
>> The NDN strategy layer chooses which is the better serving location
>> between  ndn/tw/sinica/Foo and  ndn/edu/ucla/Foo
>>
>> Only ndn/tw/sinica/ and ndn/edu/ucla/ are advertized on the global
>> routing plane,  thus reducing the FIB entries to the (e.g.) number of
>> Autonomous Systems. Plain old locator identifier split approach
>> proposed by several researchers before  me.
>>
>> Clearly, you need a secure, reliable and scalable resolution system
>> (as properly observed by DaveO) to obtain the ContentLocator field at
>> the communication session start. And also a name management system
>> that authorizes you tho name an object as Foo.
>>
>> I guess that sooner or later people mostly involved in defining the
>> NDN/CCN protocol will face this old scalability problem (I apologize
>> if you already solved this scalability issue and I miss some
>> information) .
>>
>> Conversely, as now it seems to me, this technology can be used only in
>> small closed environments, that however could be an interesting
>> use-case too, albeit with a little bit smaller impact with respect to
>> the original global scope: "Information-centric networking (ICN) is an
>> approach to evolve the Internet infrastructure"  (citing ICNRG home page)
>>
>> Andrea
> Why can this naming convention only be used on small scale, why not take
> the philosophy of the DNS convention and apply it as follows.
>
> Each name that must be publicly routable is advertised to the world
> Only top level domain should be advertised
> within each top level domain all the subdomain (or sub data) are/is only
> routable within the self domain
>
> This will allow (for example) UCLA to control and allocate names to all
> data within the UCLA network, and not have to advertise routing for it.
>
> Why not let each entity control their own naming convention, which will
> in turn also place the responsibility for routing within self on said
> entity and not on the rest of the world keeping the public routing
> tables very small.
>
> Correct me if I am completely out out line please.

In doing so, if you have a same content foo.mp4 on youtube and on vimeo, 
the content would have two different names: youtube.com/foo.mp4 and   
vimeo,com/foo.mp4. And this prevents the exploitation of multi-sources 
in a NDN, that is a relevant regression in my point of view. This is 
exactly the practical issue raised by Kuo in the initial mail of the thread.

Including in a name a prefix that is actually a routing locator (domain, 
AS, or whatever else) in my opinion is in contrast with respect to the 
initial NDN philosophy of binding communication sessions on "what" 
rather than on "where".  Moreover, in case of mobility it is well know 
that including a locator in the name may be a serious problem.

Andrea

>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>