Re: [icnrg] updated cisco packet format draft

[Andrea Detti <[e-mail]>]

On 01/08/2015 06:00 PM, [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_namingincontentoriented11.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-routing.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]> 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]
>> https://www.irtf.org/mailman/listinfo/icnrg
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg
>