Subject: Re: [icnrg] Differentianting Locator and Content Names

From: David Oran <[email-masked]>
Date: Thu, 10 Dec 2015 14:24:09 -0500

(copying whole of icnrg since I think this discussion needs full rg visibility)

Here’s my poor brain’s naive way of asking about whether the architecture treats names, identifiers, locators, or anything else differently.

1. Does the abstract service API distinguish these things, either functionally or through syntactical markers in the arguments that are used as names or the name syntax itself?

2. Does a producer, when constructing a named object, need to do something different or provide through the producer API indication of which of these things he is constructing and making available.

3. Does a router do anything different depending on whether it thinks the name in an interest or data message represents something special, like an “identifier” or a “locator”.

If the answer to any of these three questions is “yes”, then we have an architecture that distinguishes things like names, identifiers, and locators. If the answer to all three is “no” then we don’t and we should stop talking about identifiers and locators and possibly other related terms.

I believe that for the current CCN and NDN designs, the answer to all three of these questions is “no”. I also (personally) believe this is the correct approach.

That does not mean we might not have named objects that have useful semantics beyond what is above. Examples include:
- Manifests
- Link Objects that assert particular relationship between a pair of named objects.
- Trust schema objects
- Crypto key objects.

DaveO.

> On Dec 10, 2015, at 1:57 PM, GQ Wang <[email-masked]> wrote:
> 
> Marc,
>   "naming" is a forever topic. For ICN, the format of a name is not a point, but what one wants a name to function. For a named entity, if we use name to differentiate each other entities, and 
> we assume the name is "persistence", then "Name" is enough. With this regard, (KeyId, ContentObjecthash) are name's attributes which are associated with some security or operation
> context. These attribute value are optional to a named entity (saying I don't want to binding name with a key).
>   When a named entity attached to a network, the network should have another information representing the reachability or navigation for this entity, whether we call it "locator", "hints", or
> "coordinates" (saying GPS). Due to the mobility of the entity, this value should be "mutable". This attachment information could be treated as an attribute too and explicitly presented in
> a packet filed, or to be synced in the network vie signaling like OSPF-flooding, or a hybrid way.
>   Given that an ICN packet may travel through many networks with many "coordinates", that is why I think NDN "hints" should be a mutable value, instead of a fixed one.
>   Regards,
>   G.Q   
>  
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, December 10, 2015 6:57 AM
> To: Ravi Ravindran
> Cc: [email-masked]
> Subject: Re: Differentianting Locator and Content Names
>  
> What sort of differentiation are you asking for? 
>  
> I think a name is a name.  There’s only one name format and syntax.  The difference to me is if a given name is being used as a locator or an identifier, with the characteristics you describe below.  The distinction, to me, is how one would complete the sentence “This name is being used as a ____” or “The name in this field is used for ____”.  And some fields, like the current Name in an Interest, could be used for both.
>  
> One also needs to remember that a Name is not the sole term in the identifier predicate.  In CCNx, it is {Name, KeyId, ContentObjecthash}.  In NDN it is {{Name, KeyId, MinSuffix, MaxSuffix} \ {Exclude} } (with the understanding that one must always append the Data hash to the Data name) and additional steering by {ChildSelector, MustBeFresh}.  I don’t think these last two would be part of the identifier predicate as they depend on exogenous state and speak to how a Data object relates to other data objects (child selector) or the ordering of external events (must be fresh), not an intrinsic property of a Data object.
>  
> marc
>  
> On Dec 10, 2015, at 2:38 AM, Ravi Ravindran <[email-masked]> wrote:
>  
> In the last call I had raised a question on differentiating locator names from Content names, probably the question didn’t come through clearly, hope to have some discussion here.  Isn’t a consumer- in general the architecture itself- that uses these two type of names required differentiate them, as names are bound to provenance of the returned content ?. When one uses locator names, it is a transport directive, for e.g. a CDN service as was mentioned by Dave, but when the consumer uses a content name it expects a trust association with the content returned . On the other hand, with a locator name, the security/trust is fully contained in the  payload (hence application centric).
>  
> Also by definition, a locator name is assigned by the network or the service distributing the content, so shouldn’t an Interest packet with a locator name have some semantic representation in the Interest packet to say that the name represents a locator name and not a content name, so that the forwarder can handle the Interest packet with Content names differently from the one that has Locator names , such as for appropriate termination and further processing ?
>  
> Locator names generally identify hosts, storage nodes, services etc, through which the content can be retrieved , so e.g. locator name like  /akamai/eastzone/repo is name associated with a set of nodes in the CCN network, why should such names even be in the PIT  ?, in a world wither in-directions will be common such names could consume significant PIT resources. Ideally shouldn’t the state of these names only be limited to the FIB ?
>  
> Another question, that I had raised was if one were to request names with hashId as the content name learnt possibly through the manifest, assuming a small scale network, such content objects would have to be duplicated along with nameless objects in the repo, which also an efficiency issue ?
>  
>  
> Regards,
> Ravi
>  
> HUAWEI TECHNOLOGIES CO.,LTD.
> 
> Address:
> 2330 Central Expressway
> Santa Clara, 95050
> www.huawei.com
> -------------------------------------------------------------------------------------------------------------------------------------
> This e-mail and its attachments contain confidential information from HUAWEI, which 
> is intended only for the person or entity whose address is listed above. Any use of the 
> information contained herein in any way (including, but not limited to, total or partial 
> disclosure, reproduction, or dissemination) by persons other than the intended 
> recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by 
> phone or email immediately and delete it!

---

From: GQ Wang <[email-masked]>
Date: Thu, 10 Dec 2015 20:36:29 +0000

Please see our comments inline, and it should be debated.

G.Q

-----Original Message-----
From: David Oran [mailto:[email-masked]] 
Sent: Thursday, December 10, 2015 11:24 AM
To: GQ Wang; [email-masked]
Cc: Mark Mosko; Ravi Ravindran; [email-masked]
Subject: Re: Differentianting Locator and Content Names

G.Q> Yes, the APIs have to distinguish these two names, because the content name is within the application scope, and a locator name is within the infrastructure scope. For example, in NDN the link object indicates as a topological names (though this is currently scoped at the application level) which is different from a content name.

http://named-data.net/techreport/ndn-0004-2-scaling-ndn-routing.pdf

G.Q > Yes, follows the same logic as above.

G.Q > If the service APIs distinguishes this, then the forwarders should distinguish this to afford flexibility towards efficient name resolution.

G.Q> At least in the NDN case, the Link Object proposal means to distinguish between content and topological names.

G.Q > Agree with this.

DaveO.

---

From: Antonio Carzaniga <[email-masked]>
Date: Fri, 11 Dec 2015 10:52:00 +0100

| asking about whether the architecture treats names, identifiers,
 | locators, or anything else differently.

the architecture that some of us have been working on (see Papalini et
al. ICN 2014) does clearly distinguish names, identifiers, and locators
(though we prefer the concept of "descriptor" rather than "name").

Names (or descriptors) are chosen by applications.  Names/descriptors
are used for routing but their main purpose is to be meaningful to
applications.  That is, they are intended to name or describe data or
application components in a way that is meaningful to applications, but
possibly independently of the network configuration.

Identifiers are also application-defined, but their purpose is more
specific and not related to routing: they identify specific chunks of
data for the purpose of caching and transport.

Locators are chosen by the network, and their purpose is to route
efficiently, to hosts and applications.

So, the network implements *two* routing/forwarding functions: one by
name/descriptor, one by locator.

The main idea behind this distinction is that names can be expressive
for applications but may not be as efficient for routing.  Conversely,
locators can be meaningless to application but very effective for
routing.  Overall, the architecture would scale because most flows are
likely to require only a few packets addressed by descriptor and many
more packets addressed by locator.

This high-level service API should answer your specific questions on
names, locators, and identifiers.  The API is from the perspective of
the application and does not deal with identifiers, for simplicity.

  send-by-descriptor(Pkt=<descriptor=D, fanout-limit=K, ...>)
  // deliver this packet to at most K applications whose advertised
  // descriptors match descriptor D.

  send-by-locator(Pkt=<locator=L, ...>)
  // deliver this packet to the application identified by L

  get-my-locator()
  // tell me my network-defined locator

  set-my-descriptors(D1, D2, ...)
  // advertise descriptors D1, D2, ... to decide which packets
  // addressed by descriptors should be sent to me.

I think that CCN and NDN should also distinguish names (descriptors),
locators, and identifiers.

-Antonio

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 11 Dec 2015 18:26:21 +0000

This goes back to one of the points of discussion at yokohama on the need of defining these terms, i.e. identifiers, names, locators, which any ICN protocol should consider in their architecture. Another point to consider is that, the need to differentiate these in a architecture is also related to its design goals, for example CCN/NDN focussed on content distribution hence began only with content names, while others like Mobilityfirst had mobility has their key requirement hence began with a ID/Locator split consideration. Hence making a design choice in the past doesn't mean that it should lack the flexibility to evolve. For example today IoT and 5G are more compelling use cases for ICN, which requires to deal with secure IDs and handle in-network seamless mobility; not to say that they weren't before, but these are more relevant domains today where ICN can potentially enter into the mainstream discussion.

Another personal opinion with ICNRG is that, we have very limited representation from other ICN groups where there is rich set of past work. It will be good for these teams to actively bring in their ideas to discussion in the forum, so that everyone's point of view can be debated.

Regards,
Ravi

-----Original Message-----
From: Antonio Carzaniga [mailto:[email-masked]] 
Sent: Friday, December 11, 2015 1:52 AM
To: David Oran
Cc: GQ Wang; [email-masked]; Ravi Ravindran; [email-masked]; Mark Mosko
Subject: Re: [icnrg] Differentianting Locator and Content Names

  get-my-locator()

-Antonio

---

From: Anders Nilsson Plymoth <[email-masked]>
Date: Sat, 12 Dec 2015 02:08:41 +0100

Hi all,

I agree with the suggestion that this should be more properly defined,
so that we all know what we are talking about; locator, descriptor,
identifier, content name, object etc. They seem a bit stochastic at
the moment.

At TelHoc, we use the Name as a type of URI scheme, which I think
makes a lot of sense because URI's are defined for these specific
purposes.
For example, we could have a URI like this: icn://telhoc/1x3rtc
(telhoc == domain). (1x3rtc == data identifier)
This URI, is not exactly like a URL because it is not tied to a
specific location. It is be more like a URN, because it names the
resource to be accessed. However, it is actually a hybrid of the two,
where you may treat "telhoc" as a locator hint, or producer
affiliation. If a router doesn't already have the resource (object)
cached, this locator hint at least tells the router how to route the
interest in a hierarchical way.
It is also possible to go deeper:
icn://telhoc/node1/1x3rtc (hint at node within domain)
icn://telhoc/node1/app1/1x3rtc (hint at app within node)

Manifests, link objects etc can easily operate on top of these. Via
TelHoc's API, this (Name) URI is auto generated when data is stored
via the producer application. The application may also optionally
choose to set its app name and object id via the API.

In summary, I think using a URI scheme is a nice way forward for
naming as it utilizes a widely used and defined framework.
Locators, identifiers etc should be more defined in order harmonize
common language.

Thanks,
Anders

On Fri, Dec 11, 2015 at 7:26 PM, Ravi Ravindran
<[email-masked]> wrote:
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Luca MUSCARIELLO <[email-masked]>
Date: Tue, 15 Dec 2015 16:21:52 +0100

Hi Antonio,

For the kind of applications I have in mind, where NDN/CCN would be mostly
running at the network access,
early binding locators to either user's identity or data names would kill
mobility.
It would also kill in-network mechanisms like load balancing, multi-point
communications but also
in-network loss recovery and congestion control.

For the applications I care about global scalability  most likely would not
be a fundamental requirement.

Said that, IMO, the forwarder should not care about making distinctions
between locators or identifiers
otherwise we would need to introduce various levels of
translation/redirection in case of mobility.
And I would fail to see any real progress w.r.t. DNS+IP/TCP+HTTP.

So, I agree with Dave.

Luca