Subject: [Icnrg-harmonization] NDN use of nameless Data

From: <[email-masked]>
Date: Thu, 1 Sep 2016 15:23:45 +0000

There has been a bit of talk about CCNx making explicit the use of nameless objects, but I’d like to point out that one can do essentially the same thing in NDN using the Interest Link.  If CCNx were to adopt the Link approach to routing indirection, it could be done this way too (though using the ContentObjectHashRestriction field, not the implicit digest).

This is based on the 0.2-alpha-3 NDN packet format specification and the SNAMP-NDN-Scalability.pdf paper.  If I have misread something, please let me know.

The NDN spec says a Name is zero or more NameComponent.  Therefore, I can create a Data object with an empty name.  In an Interest, I can put one NameComponent of type ImplicitSha256DigestComponent and set Min/Max SuffixComponents to 0 and then include one or more Link objects in the Interest for routing.

My understanding of NDN is that because the ImplicitSha256DigestComponent is not in the FIB, a forwarder will forward via the Link.  The nameless Data Object – having 0 name components – will have a FullName of only its ImplicitSha256DigestComponent and that will match the name in the Interest.

I believe this use of NDN also maintains the property we were going after in CCNx nameless objects in that one cannot poison the cache by feting a Data object by hash that could then later be confused with a Data object being fetched by prefix or name (unless one put a 0 component name in the Interest with MaxSuffixComponents of at least 1 and used Link routing).

Marc

---

From: Ravi Ravindran <[email-masked]>
Date: Thu, 1 Sep 2016 18:24:33 +0000

But one big difference here with CCNx is that, in NDN is that all objects are named. I think we should reconsider this notion of nameless objects in CCNx, and define a way to carry locator names in the Interest messages.

Regards,
Ravi

From: Icnrg-harmonization [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, September 01, 2016 8:24 AM
To: [email-masked]
Subject: [Icnrg-harmonization] NDN use of nameless Data

Marc

---

From: <[email-masked]>
Date: Fri, 2 Sep 2016 00:02:10 +0000

I think in a way that’s a distinction without much of a difference. If one uses the convention of putting an empty name in all the “nameless” Data Objects, the only way to retrieve them is by implicit hash + link.

In CCNx we made several definitions that basically lead to using no name instead of an empty name in nameless objects.  Because we use equality match on the name and do not append the implicit digest, it made more sense to not use a name at all than use an empty name.  In NDN, because the implicit digest is appended to the Data name, using an empty name does the same thing.

One could propose doing something similar to the NDN Interest link in ccnx too.  We could put a few slides together on that to see what it looks like and talk about it.

Marc

From: Ravi Ravindran <[email-masked]>
Date: Thursday, September 1, 2016 at 11:24 AM
To: Marc <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: NDN use of nameless Data

Regards,
Ravi

Marc

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 2 Sep 2016 16:50:13 +0000

Hi Marc,

Few comments inline.

Regards,
Ravi

From: Icnrg-harmonization [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, September 01, 2016 5:02 PM
To: Ravi Ravindran; [email-masked]<mailto:[email-masked]>
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

Ravi> The point I was making is to treat Implicit hash restriction as a Name in the Interest message and not as a hash restriction, and have a separate TLV to handle locator names. To differentiate it from the exact match rule when one requests by a URI name, one has to identify it as a different type of name component in the Name TLV as in NDN. With this, the Interest processing rules don’t change ; except to calculate the hash digest of the content when it is requested by the implicit hash. This should hold good for both when a Content object is Named or Nameless (Nameless being a special type of named object as you indicate below).

Ravi > Sure agree with this because as I see it now, one has to process the Interest packet with Implicit hash differently from the ones with URI names.

Marc

From: Ravi Ravindran <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 1, 2016 at 11:24 AM
To: Marc <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: NDN use of nameless Data

Regards,
Ravi

From: Icnrg-harmonization [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, September 01, 2016 8:24 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Icnrg-harmonization] NDN use of nameless Data

Marc

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 5 Sep 2016 17:12:01 -0700

> This is based on the 0.2-alpha-3 NDN packet format specification and the SNAMP-NDN-Scalability.pdf paper.  If I have misread something, please let me know.

Personal opinion: I am afraid that the above reflects a misunderstanding of NDN names and the role of LINK object.

> The NDN spec says a Name is zero or more NameComponent. 

I do not agree with the "nameless object" concept (in fact CCNx 1.x's nameless object indeed has a name, the content hash), and I do not believe NDN names allow zero component. 
 
I just looked at the spec and did not see such statement; I searched the page, the only appearance of the word "zero" is in describing how to "unambiguously represent name components that would collide with the use of . and .. for relative URIs"

If I missed anything, please point out to me and we'll fix it.

Lixia

PS: there seems a huge conceptual confusion about names and locators, that we really to clean up someday soon.

> Therefore, I can create a Data object with an empty name.  In an Interest, I can put one NameComponent of type ImplicitSha256DigestComponent and set Min/Max SuffixComponents to 0 and then include one or more Link objects in the Interest for routing.
>  
> _______________________________________________
> Icnrg-harmonization mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/icnrg-harmonization <https://www.irtf.org/mailman/listinfo/icnrg-harmonization>

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 5 Sep 2016 17:13:52 -0700

> On Sep 1, 2016, at 11:24 AM, Ravi Ravindran <[email-masked]> wrote:
> 
> But one big difference here with CCNx is that, in NDN is that all objects are named.

Yes, hence the name of the architecture: named data networking :-)

> I think we should reconsider this notion of nameless objects in CCNx, and define a way to carry locator names in the Interest messages.
>  
> Regards,
> Ravi

To me the so called "locator" is another misconception.

Lixia

> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg-harmonization

---

From: <[email-masked]>
Date: Tue, 6 Sep 2016 00:51:27 +0000

On Sep 5, 2016, at 5:12 PM, Lixia Zhang <[email-masked]<mailto:[email-masked]>> wrote:

On Sep 1, 2016, at 8:23 AM, [email-masked]<mailto:[email-masked]> wrote:

It might not be in accordance with the intention, but I think it is allowed by the definitions.

Is it supposed to be illegal to use only hash-based naming in NDN?  We had talked about that usage some back in the early CCNx days, using only an implicit hash, or a name simply like “/objectstore/<implicithash>”.

From this page http://named-data.net/doc/ndn-tlv/name.html

Name ::= NAME-TYPE TLV-LENGTH NameComponent*

It’s my understanding that an * means zero or more, i.e. optional.  If you want it to be 1 or more, then change it to “+”, as I think your pages are using regex-like syntax not ABNF.

However, I don’t think that’s what you want to do, because you probably use a zero-component name to indicate the default route.  So, you probably need to either define a non-zero name and use that in the Data definition, or add some text in the paragraph that defines the name to say it cannot be a zero-length name.  I’d personally use the first approach as the regex/ABNF should be the authoritative definition, not the text.

Lixia

Marc
_______________________________________________
Icnrg-harmonization mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg-harmonization

_______________________________________________
Icnrg-harmonization mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/icnrg-harmonization

---

From: GQ Wang <[email-masked]>
Date: Tue, 6 Sep 2016 01:05:41 +0000

From my understanding, the "link" in NDN represents a "domain", whether it is interpreted as ownership domain, routing domain or some else domain.
The domain has a container relationship with the named object. In NDN/CCN, the domain is used for navigating the reachability of a named object,
it is either representing a home server/network, a attachment point, a storage, etc, for the data acquiring operation.
Regards,
G.Q

From: Icnrg-harmonization [mailto:[email-masked]] On Behalf Of Lixia Zhang
Sent: Monday, September 05, 2016 5:14 PM
To: Ravi Ravindran
Cc: [email-masked]; [email-masked]
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

On Sep 1, 2016, at 11:24 AM, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:

Regards,
Ravi

Lixia

Marc

---

From: Alex Afanasyev <[email-masked]>
Date: Mon, 5 Sep 2016 21:21:38 -0700

> The NDN spec says a Name is zero or more NameComponent.  Therefore, I can create a Data object with an empty name.  In an Interest, I can put one NameComponent of type ImplicitSha256DigestComponent…

The fact that generic definition of the name allows zero component is not related to the fact that ALL data packets have name.  Name is the identifier of the data.  (What Lixia is arguing is that Interest packet must not have an empty name, as Interest should ask for something.  This part is an oversight in the current spec.)

In my opinion, there is no "nameless" Data in NDN.  I would like to say it even more generally, that in ICN there could not be "nameless" data, as name is data's identifier.  I understand that in CCNx 1.x spec you redefined the concept of the name, which creates a lot of confusion.

I would like also to reiterate my opinion that not properly naming each individual data packet is a serious limitation.  Yes, manifest and etc. can provide contexts to verify data, but it is really limitings.  Data packet by itself is worthless, as there is neither application context to which this packet belong nor security context to verify it.

And additional point.  I would like to bring back the conversation we had last week, where we pointed out that there are many cases where consumer inherently cannot know neither the full nor exact name.  Therefore, I'm not quite sure where are we going with this conversation.  In general, each Data packet should have a unique name.  And in many cases, such as real-time data retrieval, the name should use predictable naming conventions, at the very least to allow pipelining of interests.

---
Alex

---

From: <[email-masked]>
Date: Tue, 6 Sep 2016 04:59:13 +0000

On Sep 5, 2016, at 9:21 PM, Alex Afanasyev <[email-masked]<mailto:[email-masked]>> wrote:

I would say the full name (including the implicit hash) is the unique identifier of the data.  The prefix is for routing and the application data (version, segment, etc.) is for application conventions and in some cases discovery.  If I’m willing to route on hashes and have some other means of discovery, I don’t think it should be illegal to do that.

An Interest packet would have the implicit hash, so it would have a non-empty name field.

Really, we went back to the ability of CCNx 0.7 (and earlier) to use only hash-based naming, which was an ability that CCNx 1.0 lost when we split the hash restriction out of a name component and put it in a distinguished field.  If you go back and look at the old CCNx specs, you’ll see they permitted empty names too (https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/Name.txt).  You could also look at the old ccnx.dtd and ccnx.xsd, they specifically allow zero component names.

What we added was a rule about not matching the Interest name if the ContentObject had no name field, which is different from the CCNx 0.x days and introduced a locator.

Most data packets, by them self, are worthless; a single data packet is usually only a small fraction of some larger whole.  There are a small number of data packets that must be discoverable because those will lead one to knowing how to retrieve the remainder of the data.

I am not making the point that all data or apps must do it this way.  I understand there are cases when one wants predictable names and discoverable names.

Not in general, but in specific, all data packets do have unique names via the implicit hash.  I think what you want to mandate is that all data packets have unique exact names (up to but not including the implicit hash).  You can have a recommendation that a producer not generate duplicate names, but there’s no way to enforce that in the system.

Would you completely rule out a NDN-based system that uses implicit hash names without some other prefix, even if those implicit hash names were in the FIB?

---
Alex

Marc

---

From: Alex Afanasyev <[email-masked]>
Date: Mon, 5 Sep 2016 22:11:37 -0700

> On Sep 5, 2016, at 9:59 PM, [email-masked] wrote:
> 
> 
>> On Sep 5, 2016, at 9:21 PM, Alex Afanasyev <[email-masked] <mailto:[email-masked]>> wrote:
>> 

The point I was making is that there are no "nameless" data.  Each data packet has a name (full name), which identifies this specific data packet at the networking level.

> Really, we went back to the ability of CCNx 0.7 (and earlier) to use only hash-based naming, which was an ability that CCNx 1.0 lost when we split the hash restriction out of a name component and put it in a distinguished field.  If you go back and look at the old CCNx specs, you’ll see they permitted empty names too (https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/Name.txt <https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/Name.txt>).  You could also look at the old ccnx.dtd and ccnx.xsd, they specifically allow zero component names.
> 

Discoverable is for cases when exact name is not known.  I would agree that there is a small number of those.  There is a way greater amount of packets which are not yet generated, but the consumer would want to send interest to retrieve them (real time pipeline as an example here, but there are other cases such as IoT/DTN).

> Would you completely rule out a NDN-based system that uses implicit hash names without some other prefix, even if those implicit hash names were in the FIB?

What I said does not rule this out.  In my opinion, this type of usage is possible, while applicable only to certain cases.

--
Alex

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 05:23:32 +0000

I’m not sure if there is any disagreement about this that, there are two types of names in ICN, one what application binds to, and managed by the application providers, called identifiers. And the names that are relevant to the network layer to identify networks, routers, border nodes, hosts etc, managed by the infrastructure provider, hence topological and can be used for routing, late binding etc, which we call locators.

Isn’t the link defined in SNAMP paper same as locators ?

Regards,
Ravi

From: Lixia Zhang [mailto:[email-masked]]
Sent: Monday, September 05, 2016 5:14 PM
To: Ravi Ravindran
Cc: [email-masked]; [email-masked]
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

Regards,
Ravi

Lixia

Marc

---

From: Alex Afanasyev <[email-masked]>
Date: Mon, 5 Sep 2016 23:11:33 -0700

> On Sep 5, 2016, at 10:23 PM, Ravi Ravindran <[email-masked]> wrote:
> 

I don't fully agree with the distinction.  Some names will be managed by the operators.  However, it does not mean that only those names can be used to forward Interests.  While I cannot predict future for real, I can see that prefixes for the "popular data" (e.g., from google, amazon, netflix, etc.) will be reachable directly.

If we still have routing system similar to what we have today (I'm leaving the door open here), then not-so-popular application data would need to be mapped to other names that can guide the interests.

> Isn’t the link defined in SNAMP paper same as locators ?

I think this is a continuation of the discussion we had a few meetings back.  There is similarity, but there is also semantical differences from what word "locator" implies:

- (1) The link from SNAMP paper is a hint for the routers on where the data may be available.
- (2) The link does not imply that interests must be forwarded to a specific "location" to retrieve data, e.g., data can be retrieved from without using the link or on the way(s) pointed by the link.
- (3) The name in the link might not be even a "location", just a direction(s) or way(s) to follow to have a chance to meet the data.  Here I would like to highlight the fact that some name prefixes would be announced from different places, i.e., the way(s) to meet the data is not pre-determined.

--
Alex

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 14:32:51 +0000

I agree with the distinction between link and locator, but in administered domains 'links' will most likely will  be used as locators, as you have absolute knowledge of the cache/storage, or the attachment point of the device etc. In this case, links can be given priority over the names in the Interest packet, and avoid trying to route on both these names simultaneously.

Regards,
Ravi

-----Original Message-----
From: Alex Afanasyev [mailto:[email-masked]] 
Sent: Monday, September 05, 2016 11:12 PM
To: Ravi Ravindran
Cc: Lixia Zhang; [email-masked]; [email-masked]
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

--
Alex

---

From: David Oran <[email-masked]>
Date: Tue, 6 Sep 2016 10:53:27 -0400

> On Sep 6, 2016, at 10:32 AM, Ravi Ravindran <[email-masked]> wrote:
> 
This to me illustrates very well why the term “locator” is really problematic in the context of ICN. Let’s get rid of it.
There are two related but separate functions:

a) how does a forwarder match an interest to either a local application or a cached copy of the data object.
b) how does a forwarder decide where to forward the interest if (a) above returns “not found”.
Neither of these requires anything like a locator.

A forwarder can use any information it has at its disposal to figure (b) out. It could have a useful LPM entry in its FIB matching a prefix of the name in the interest. It could consult an oracle. It could send the Interest to the CIA (who knows where the data is). If could send the interest to the NSA, who undoubtedly already has it. It could us a hint in the Interest message (e.g. a Link). None of these is a “locators”. Or perhaps they all are, in which case the term is equally usless.

---

From: "Thompson, Jeff" <[email-masked]>
Date: Tue, 6 Sep 2016 15:48:58 +0000

> b) how does a forwarder decide where to forward the interest if (a)
>above returns ³not found².

The forwarder has to decide where to forward the interest to get a data
packet which not only has a matching name, but has a signature that the
consumer will trust (since it is the consumer who verifies the packet). In
a future Internet with a billion producers, most of them mobile, there
could be many packets floating around with a matching name, but only one
with a signature that the consumer will trust. I had always assumed that
this is why the consumer has to put something in the interest - not to
tell the network where to find a data packet with a matching name (too
easy), but where to find a producer who will cough up a data packet with a
signature that the consumer will trust.

- Jeff T

On 2016/9/6, 7:53:27, "Icnrg-harmonization on behalf of David Oran"
<[email-masked] on behalf of [email-masked]>
wrote:

>> I agree with the distinction between link and locator, but in
>>administered domains 'links' will most likely will  be used as locators,
>>as you have absolute knowledge of the cache/storage, or the attachment
>>point of the device etc. In this case, links can be given priority over
>>the names in the Interest packet, and avoid trying to route on both
>>these names simultaneously.
>> 
>This to me illustrates very well why the term ³locator² is really
>problematic in the context of ICN. Let¹s get rid of it.
>b) how does a forwarder decide where to forward the interest if (a) above
>returns ³not found².
>A forwarder can use any information it has at its disposal to figure (b)
>out. It could have a useful LPM entry in its FIB matching a prefix of the
>name in the interest. It could consult an oracle. It could send the
>Interest to the CIA (who knows where the data is). If could send the
>interest to the NSA, who undoubtedly already has it. It could us a hint
>in the Interest message (e.g. a Link). None of these is a ³locators². Or
>perhaps they all are, in which case the term is equally usless.
>
>
>
>> Regards,
>> Ravi
>> 
>>> I¹m not sure if there is any disagreement about this that, there are
>>>two types of names in ICN, one what application binds to, and managed
>>>by the application providers, called identifiers. And the names that
>>>are relevant to the network layer to identify networks, routers, border
>>>nodes, hosts etc, managed by the infrastructure provider, hence
>>>topological and can be used for routing, late binding etc, which we
>>>call locators.
>> 
>> I don't fully agree with the distinction.  Some names will be managed
>>by the operators.  However, it does not mean that only those names can
>>be used to forward Interests.  While I cannot predict future for real, I
>>can see that prefixes for the "popular data" (e.g., from google, amazon,
>>netflix, etc.) will be reachable directly.
>> 
>> If we still have routing system similar to what we have today (I'm
>>leaving the door open here), then not-so-popular application data would
>>need to be mapped to other names that can guide the interests.
>> 
>>> Isn¹t the link defined in SNAMP paper same as locators ?
>> 
>> I think this is a continuation of the discussion we had a few meetings
>>back.  There is similarity, but there is also semantical differences
>>from what word "locator" implies:
>> 
>> - (2) The link does not imply that interests must be forwarded to a
>>specific "location" to retrieve data, e.g., data can be retrieved from
>>without using the link or on the way(s) pointed by the link.
>> - (3) The name in the link might not be even a "location", just a
>>direction(s) or way(s) to follow to have a chance to meet the data.
>>Here I would like to highlight the fact that some name prefixes would be
>>announced from different places, i.e., the way(s) to meet the data is
>>not pre-determined.
>> 
>> --
>> Alex
>> 
>>> 
>>> Regards,
>>> Ravi
>>> 
>>> I think we should reconsider this notion of nameless objects in CCNx,
>>>and define a way to carry locator names in the Interest messages.
>>> 
>>> Regards,
>>> Ravi
>>> 
>>> From: Icnrg-harmonization
>>>[mailto:[email-masked]] On Behalf Of
>>>[email-masked]
>>> There has been a bit of talk about CCNx making explicit the use of
>>>nameless objects, but I¹d like to point out that one can do essentially
>>>the same thing in NDN using the Interest Link.  If CCNx were to adopt
>>>the Link approach to routing indirection, it could be done this way too
>>>(though using the ContentObjectHashRestriction field, not the implicit
>>>digest).
>>> 
>>> This is based on the 0.2-alpha-3 NDN packet format specification and
>>>the SNAMP-NDN-Scalability.pdf paper.  If I have misread something,
>>>please let me know.
>>> 
>>> The NDN spec says a Name is zero or more NameComponent.  Therefore, I
>>>can create a Data object with an empty name.  In an Interest, I can put
>>>one NameComponent of type ImplicitSha256DigestComponent and set Min/Max
>>>SuffixComponents to 0 and then include one or more Link objects in the
>>>Interest for routing.
>>> 
>>> My understanding of NDN is that because the
>>>ImplicitSha256DigestComponent is not in the FIB, a forwarder will
>>>forward via the Link.  The nameless Data Object  having 0 name
>>>components  will have a FullName of only its
>>>ImplicitSha256DigestComponent and that will match the name in the
>>>Interest.
>>> 
>>> I believe this use of NDN also maintains the property we were going
>>>after in CCNx nameless objects in that one cannot poison the cache by
>>>feting a Data object by hash that could then later be confused with a
>>>Data object being fetched by prefix or name (unless one put a 0
>>>component name in the Interest with MaxSuffixComponents of at least 1
>>>and used Link routing).
>>> 
>>> Marc

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 18:17:30 +0000

I'm OK with using the terms Link or Hints, its use as a locator is a special case, considering the scope of the Link Alex mentioned. But the forwarder should be able to distinguish these two behavior, i.e. use it as a hint or use it as explicit locator considering different network contexts.

Regards,
Ravi

---

From: David Oran <[email-masked]>
Date: Tue, 6 Sep 2016 14:20:14 -0400

> On Sep 6, 2016, at 2:17 PM, Ravi Ravindran <[email-masked]> wrote:
> 
What do you think the difference is? I don’t see any.

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 18:31:36 +0000

The difference is, if the network has knowledge of a resource, and explicitly knows how to reach it via a link that encodes a named storage service, host, or a border node that takes the interest to another domain. Then the network should be able to mark it (also insert such a link if required) so that the forwarder uses the link to route the Interest to that name, instead of working with an assumption that finding the resource with the Interest name and the link is equally likely.

Regards,
Ravi

---

From: David Oran <[email-masked]>
Date: Tue, 6 Sep 2016 14:50:07 -0400

> On Sep 6, 2016, at 2:31 PM, Ravi Ravindran <[email-masked]> wrote:
> 
> The difference is, if the network has knowledge of a resource, and explicitly knows how to reach it via a link that encodes a named storage service, host, or a border node that takes the interest to another domain.
Why isn’t that just a FIB entry? What am I missing?

> Then the network should be able to mark it (also insert such a link if required) so that the forwarder uses the link to route the Interest to that name,
that’s an interesting design point, independent of the whole locator thing. Should forwarders be allowed to insert routing hints, or only consumers? What kind of on-path attacks get opened by this? Can forwarding paths be diagnosed better/worse if this is allowed? Who is responsible for checking the signature on such routing information? Is am I ok with the Russian ISP checking signatures on links purporting to point to the U.S. but signed by the North Koreans?

> instead of working with an assumption that finding the resource with the Interest name and the link is equally likely.
The “likeliness” is usually represented by routing metrics. Why invent something special?

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 18:59:41 +0000

Within the context of Interest Names and Links, there is nothing new here. My point is about the semantics of a link and its interpretation by the network, which can vary with different situations and has to be accommodated. For e.g. in our implementations, we implement CCN routing using ONOS. Here the links are inserted by the edge nodes, and used to route in the network. And for something like mobility there is no state for the Interest names in the network at all, hence with this knowledge looking up by the name is of no use.

Regards,
Ravi

---

From: Alex Afanasyev <[email-masked]>
Date: Tue, 6 Sep 2016 12:02:33 -0700

> On Sep 6, 2016, at 11:59 AM, Ravi Ravindran <[email-masked]> wrote:
> 

If the network doesn't use the application names, wouldn't it be equivalent (=straightforward) to just encapsulate both Interest and Data packets into a special "network adaptation" protocol to move them within that network?

---
Alex

---

From: Ravi Ravindran <[email-masked]>
Date: Tue, 6 Sep 2016 19:12:57 +0000

I think this discussion would be on similar lines with the discovery mechanism, if you want to overload the network to handle this feature or handle it as an overlaid protocol.

But I think the situation is simpler here,  considering NDN already proposes the link usage in the Interest packet, which is not different from forwarding-labels we discuss in our draft. The main difference here is with its semantics, and to broaden its scope to include its management by the infrastructure provider as well.

Regards,
Ravi

-----Original Message-----
From: Alex Afanasyev [mailto:[email-masked]] 
Sent: Tuesday, September 06, 2016 12:03 PM
To: Ravi Ravindran
Cc: Dave Oran; [email-masked]; Lixia Zhang; Mark Mosko
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

---
Alex

---

From: David Oran <[email-masked]>
Date: Wed, 7 Sep 2016 08:58:05 -0400

> On Sep 6, 2016, at 3:12 PM, Ravi Ravindran <[email-masked]> wrote:
> 
For the use case Ravi is focused on (control of forwarding by an administrative domain when Interests arrive at a domain boundary), it seems that tunneling is superior to using Link objects or routing hints. This is so that the policing of ingress and checking of the authenticity of Link objects only has to be done at entry, and not at every hop.

Otherwise, domains will do ugly things like removing link objects at the domain boundary in order to protect the forwarding behavior of their interior forwarders. We’ve seen similar lossage with IP where ISPs blow away DSCPs and ECN marks on entry; I’d rather not repeat those mistakes with ICN.

DaveO.

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 7 Sep 2016 16:27:30 +0000

Not sure, how tunneling is different from overwriting link objects, isn’t it serving the same purpose ?. Rather than seeing it doing ugly thing, my opinion is that in a virtualized ICN infrastructure, there will be a lot of customization of services. So if the provider is offering content delivery or providing mobility service to particular name prefix, it should have the ability leverage the domain knowledge to handles those Interest flows more intelligently.
IMO, for a good foreseeable future we are going to have a demarcation between the users and the infrastructure providers, and flows are going to subjected to policies that benefit its network and users.

Regards,
Ravi

-----Original Message-----
From: David Oran [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2016 5:58 AM
To: Ravi Ravindran
Cc: Alex Afanasyev; [email-masked]; Mark Mosko; Lixia Zhang
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

DaveO.

---

From: David Oran <[email-masked]>
Date: Wed, 7 Sep 2016 13:12:21 -0400

> On Sep 7, 2016, at 12:27 PM, Ravi Ravindran <[email-masked]> wrote:
> 
> Not sure, how tunneling is different from overwriting link objects, isn’t it serving the same purpose ?.
No, With tunneling the original Interest with any Link objects or other directives, pops out at the tunnel endpoint,  rather than having been over-written.

> Rather than seeing it doing ugly thing, my opinion is that in a virtualized ICN infrastructure, there will be a lot of customization of services.
Sure. That’s not my point. My point was that ISPs often over-ride user intent. If the user does not put directives in the Interest the ISP is obviously free to optimize anything they want. On the other hand, if the Interest arrives with some directives (including things like a Link object that might divert the Interest to some other path), the ISP ought not to delete it or override it in order to force traffic onto their own CDN or other service.

> So if the provider is offering content delivery or providing mobility service to particular name prefix, it should have the ability leverage the domain knowledge to handles those Interest flows more intelligently.
Sure, modulo the cautions I mention above.

> IMO, for a good foreseeable future we are going to have a demarcation between the users and the infrastructure providers,
This statement makes me very nervous, as it harkens back to the old Bell-shaped heads that divided the world inappropriately into UNIs and NNIs.

>  and flows are going to subjected to policies that benefit its network and users.
Where those interests are aligned, of course. For better or worse, that’s not always the case.

DaveO.

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 7 Sep 2016 17:56:24 +0000

". On the other hand, if the Interest arrives with some directives (including things like a Link object that might divert the Interest to some other path), the ISP ought not to delete it or override it in order to force traffic onto their own CDN or other service."

- Why ?, what if the ICN services are hosted in my edge cloud, there should be a cheaper solution to re-direct the Interest instead of costly tunneling process. We can still keep the link-object, if one want to carry the overhead, add another forwarding label and re-direct it. That way the edge service still gets the Interest with the original Link object header.

Regards,
Ravi

-----Original Message-----
From: David Oran [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2016 10:12 AM
To: Ravi Ravindran
Cc: Alex Afanasyev; [email-masked]; Mark Mosko; Lixia Zhang
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

DaveO.

---

From: <[email-masked]>
Date: Wed, 7 Sep 2016 18:15:09 +0000

In SNAMP, the Interest Name is always used first, then the Link(s) if the name cannot be matched in the FIB.  If you want to do some traffic engineering routing on the Interest in your domain, I think putting your own domain-specific label on the Interest is the right thing to do.  You do one name/link lookup on ingress, make a decision, then execute on that decision, not repeat it at every hop.  When the Interest egresses your domain, the Interest name and Link(s) are as they were when they entered your domain.

If your domain is authoritative for the name, you should be ignoring the Link(s) anyway, as the name should be in your FIB.  So if you have proper routing for the name, then tunneling and links are not needed.  If you want to do traffic engineering routing that is not easily handled with shortest path routing, then you want to tunnel.

Marc

> On Sep 7, 2016, at 10:56 AM, Ravi Ravindran <[email-masked]> wrote:
>

---

From: Ravi Ravindran <[email-masked]>
Date: Wed, 7 Sep 2016 19:06:28 +0000

I agree with Marc's note that use of tunneling is OK if the decision is purely for TE purpose or routing based on private names as the case of VPNs today. But if it is a service-centric decision, then forwarding based on domain based labels should be permitted.

Regards,
Ravi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, September 07, 2016 11:15 AM
To: Ravi Ravindran
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

Marc

---

From: GQ Wang <[email-masked]>
Date: Wed, 7 Sep 2016 19:11:30 +0000

Both "link" and "forwarding label" are used for directive purpose. The difference is the operational semantics.
"link" is more like a domain or home container of a named object, which is specified by consumer and never be
updated in the route; while "forwarding label" is used for late-binding of attachment point of a named object
in mobility, and is subjected to be updated along the way.
Because a named object/entity is always attached to some points of ICN, whether they are home domain server or
a base station (fixed vs. dynamic). IMO we can generalize "link" operation semantic to serve for both usage cases.
Regards,
G.Q

-----Original Message-----
From: Icnrg-harmonization [mailto:[email-masked]] On Behalf Of David Oran
Sent: Wednesday, September 07, 2016 10:12 AM
To: Ravi Ravindran
Cc: [email-masked]; Lixia Zhang; Mark Mosko; Alex Afanasyev
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

DaveO.