Re: [icnrg] Locator hint

[Ravi Ravindran <[e-mail]>]

We had also presented this draft in an earlier ICN-RG meeting, we will have a revision of this draft for the next meeting.

https://tools.ietf.org/html/draft-ravi-ccn-forwarding-label-00

regards,
Ravi

From: icnrg [mailto:[e-mail]] On Behalf Of Andrea Detti
Sent: Friday, October 16, 2015 12:23 AM
To: [e-mail]
Subject: Re: [icnrg] Locator hint

Dear All,
do you remember this old discussion?

Citing DaveO "While we may be forced into doing something like this ultimately....".

Well, this email is just to point out that NDN team embraced the Locator Hint, aka Link Object, principles in their NFD software, with a clever technique to avoid cache poisoning .

References:

http://redmine.named-data.net/attachments/download/427/forwarding-hint_20150814.pptx
http://named-data.net/wp-content/uploads/2015/03/SNAMP-NDN-Scalability.pdf
see also "network_region" configuration section in nfd.conf

Regards,

Andrea



On 09/01/2015 23:38, Andrea Detti wrote:
Great news.
Is there already a document presenting these interesting features or it will be released shortly ?

Andrea



On 01/09/2015 08:06 PM, [e-mail]<mailto:[e-mail]> wrote:

CCN 1.0 has gone major revisions since the old CCN.  In the current system
there are a number of features that make these issues less of a problem.

Specifically, we have Manifests and Name-less objects.  These basically
allow you to have name indirection and objects hosted independently of
location.

The name, which for us is a network name, is what the network uses to find
stuff. It¹s easy to thing of this as the same as the user defined name.
In some cases it is, but in some cases it might not be.

In CCN we can currently use manifests to do a form of secure translation
of one name to another. There are some limitations in terms of publisher
but the primitives are currently holding up for what we want to achieve.

So, to answer your initial question, I think that the primitives we have
right now can give you a lot of what you¹re looking for.  Will we need to
have some extra locator or some other scalability mechanism?  Maybe, but I
think we can get far with the primitives we currently have.

Nacho


--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
[phone]
[e-mail]<mailto:[e-mail]>





On 1/9/15, 10:26 AM, "Andrea Detti" <[e-mail]><mailto:[e-mail]> wrote:


I agree on all your points.

Consequently, I see two choices in front of us before to think to use
ICN in the global scale:

1) either we found a reasonable way to scale the routing by object name
(including mobility and multi-destinations/multi-sources cases);
2) or we found a reliable and secure translation mechanism.

Which of two will require less effort?

I do not know :-)

Andrea



On 01/09/2015 06:21 PM, David Oran wrote:

While we may be forced into doing something like this ultimately, every
time you introduce a level of indirection via some kind of translation
function, you dramatically increase the attack surface against the
system. Not only do you have to secure the input and the output values
in the packets, you also have secure the translations against spoofing
and the service that performs the translation against the full panoply
of vulnerabilities.

Routing hints are particularly tricky. I recall a proposal for NDN
routing hints that was presented at a recent NDN retreat that looked
superficially clever, but collapsed in a heap of security problems after
a few hours of scrutiny.

Invalidation of mappings is also quite delicate for routing systems
where the expectations of routing disruption durations are much shorter
than say, name mapping disruptions in systems like DNS due to
translation cache TTLs.

One thing that makes routing hints (as opposed to name->name
translations) particularly tricky for NDN/CCN-like architectures is
doing them in a way that does not break or substantially constrain
multi-destination delivery. It¹s much easier to do this with
single-destination delivery - one example of a full-worked scheme is the
LISP mapping service for IP.

DaveO.



On Jan 9, 2015, at 2:30 AM, Andrea Detti <[e-mail]><mailto:[e-mail]>
wrote:

On 01/08/2015 06:00 PM, [e-mail]<mailto:[e-mail]> wrote:

PARC will be releasing the next version of our working documents
shortly, before the icnrg meeting.  We have for a while supported an
Interest carrying a Payload field that can carry extended information
that is not part of the name.  Intermediate nodes do not process the
payload.

If the payload can make a difference to a dynamic content publisher,
then the requester must put a marker of the payload in the name ‹ i.e.
put the hash of the payload a a name component, or use a nonce.  This
will allow proper multiplexing of different payloads in the name.
I see that this is a way to indicate to the router which is the part
of the name that is relevant for the PIT/FIB purposes. And it sounds
good to me, since it speeds up the lookup processes.

However, let me pose a more general question: is it really "ICN
mandatory" to use a component of the object name to forward?

What we would lose, if we used the object name only for PIT and
caching operations and (optionally) another "routing info" field
completely decoupled from the name for FIB forwarding purposes?

If we do not lose so much, why do not open an ICN 1.01 phase (2.0 was
too ambitious ;-))  in which we recognize that routing by object name
creates scalability problem in the large area, and so in these cases
ICN can be helped by a plain old by routing by locator (aka routing
info, routing hint, label, forwarding alias, etc.)?

If this was obvious, probably it is now the right time to define such
a TLV. Simirarily to KeyLocator we could define a ContentLocator that
specifies a (or more) routable Name where it it is possible to found
the object.

I know that I am rediscovering the wheel since many other excellent
projects/researchers before have predicted that, e.g.

SAIL project 2010 ­ ³Routing hints²

S. Shenker, 2011 - Naming in content-oriented Architectures: ³Šthe
fetch-terms enable the routing system to more easily find the object²

http://www.icsi.berkeley.edu/pubs/networking/ICSI_namingincontentoriente
d11.pdf

Presentation of D. Oran, 2011 - NDN and IP Routing: Can it scale? ­
³ŠUse a translation lookup to convert from content name to routing
label(s)²

http://tools.ietf.org/group/irtf/trac/raw-attachment/wiki/icnrg/IRTF%20-
%20CCN%20And%20IP%20Routing%20-%202.pdf

Hermans et. al,  2012 - Global source mobility in the content-centric
networking architecture- ³Separate namespaces for identifier and
locators².
http://user.it.uu.se/~frehe489/publications/hermans12global.pdf

L. Zhang, 2013 - Scaling NDN Routing: Old Tale, New Design,
³Application names are used for caching and signature verification,
while the forwarding alias, which reflects the service provider of the
content producer, serves as a hint to routers about where the packet
may be forwarded²

http://named-data.net/wp-content/uploads/2014/08/ndn-tr-4-scaling-ndn-ro
uting.pdf

N. Solis (PARC developer of CCNx 1.0), presentation at CCNxCon 2013 ­
Ordered-Element Naming (OEN), ³I presented a matching system with order
of preference based on labels (which included hashes of content)²
http://www.ccnx.org/events/ccnxcon-2013/

      Regards,

Andrea

It is not mandatory that applications do this ‹ some data might
rightly belong in the name.

Using this method relieves the forwarding plane from having to
process and store in the PIT large names that make no difference in
routing.  It also means that the potentially large payload does not
need to be echoed back to the client in the response name.

The previous PARC spec is at
http://www.ccnx.org/pubs/ccnx-mosko-tlvmessages-02.html
.  It will be updated in the next day or so and we will send an email
to the list.

Marc

On Jan 8, 2015, at 8:19 AM, Mark Stapp
<[e-mail]><mailto:[e-mail]>
   wrote:



On 1/8/15 4:24 AM, Andrea Detti wrote:


Dear Mark,

I found rather interesting this question

"Is it really necessary to continue to force all of the information
in
Interests into the Name?  Wouldn't it be clearer to use the Name
only
for publisher/routing info, object name info, and segment/sequence
number?"

and wonder ICN community think about that. Especially with respect
to
the routing info.

That specific question has been open for quite a long time - not
really in the routing context however. One position has been that
Interests carry "only" a name, and therefore all application-specific
data must be in the name. Now in fact Interests have been permitted
to carry several additional "meta" items - such as filters/selectors
(another open topic) and timeout values. Another position asks
whether there are types of application-specific data that could also
be carried outside the Interest name. We've asked whether REST-ful
application state transfer might be one example.



I see a scalability problem with the ICN routing plane,
yes, of course - that's a very long-standing problem.

especially when


objects are multi-sourced (same object on my PC and on my phone) and
objects are provided by mobile devices.  This framework could be the
norm in the future.
that's ... certainly an assertion I've heard before, but "could be"
is about as strong as it gets. there are a lot of questions about
whether encapsulation mechanisms, or "name resolution" mechanisms, or
some other mechanisms will be needed to deal with the expected name
scale, whether or not there will be any significant of peer-to-peer
communication. personally, I think it's highly unlikely that my phone
will "publish" anything directly, but that's just another speculation
really.

at the moment, I'd be happy if there could be progress on even the
most basic aspects of messaging - such as what names look like,
something that seems truly fundamental.

Thanks,
Mark

_______________________________________________
icnrg mailing list

[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list

[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg


_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg
_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg


_______________________________________________
icnrg mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/icnrg