Subject: [icnrg] updated cisco packet format draft

From: Mark Stapp <[email-masked]>
Date: Tue, 06 Jan 2015 15:31:33 -0500

I'm sending around an updated version of the draft describing our 
thoughts on ndn/ccn packet encoding, in preparation for the interim 
meeting next week. Comments welcome, of course!

Regards,
Mark

---

From: [email-masked]
Date: Wed, 7 Jan 2015 06:28:23 +0100 (CET)

Hi Mark,

nice to have yet another packet format!

To make the point that packet formats can be switched like socks (and 
are not the real issue for walking), I quickly added support for it to 
CCN-lite. Basic tests for classic ICN style fetch, even with segment 
numbers, pass; but I have not tested NFN-over-cisco2015 yet. Much of the 
coding was copy-paste and I could fill in the draft's blanks with 
borrowing from the other suites, they are all so similar.

For those interested in the code: it's in the "cistlv" branch at
https://github.com/cn-uofbasel/ccn-lite/tree/cistlv

See you next week!
Best, christian

PS: more interesting than socks is the way to switch socks: over time, 
while you walk, per domain and on demand.

On Tue, 6 Jan 2015, Mark Stapp wrote:

> I'm sending around an updated version of the draft describing our thoughts on 
> ndn/ccn packet encoding, in preparation for the interim meeting next week. 
> Comments welcome, of course!
>
> Regards,
> Mark
>

---

From: Mark Stapp <[email-masked]>
Date: Wed, 07 Jan 2015 10:27:42 -0500

Hi Christian (and Happy New Year to you and yours)

I think you realize that the real issues are more complex, that the real 
issues are about what can be expressed, what features are necessary, and 
what is a reasonable minimum set of primitives that allows us to 
experiment. This ongoing discussion is hopefully making things more 
concrete and more verifiable. And hopefully that may help clarify what 
works and what does not - at least it seems so to me. And continuing to 
work out some common ground rules lets us experiment together, rather 
than in parallel.

Now as you may remember I am not a particular fan of socks, though I 
support the right of each individual to choose for him/herself. Do you 
know Dr Seuss, the childrens' book writer? Here's a little doggerel in 
that style:

Dumb bits fits
In socks' knits,
Such soft socks
Walk on rocks,
Quick Basel fox,
Switch Swiss socks!
Signed Swiss socks?
Such signed socks,
Stuck in box!

Cheers,
Mark

---

From: [email-masked]
Date: Wed, 7 Jan 2015 17:52:28 +0100 (CET)

:-)

Yes, Dr Seuss and the Marx Brothers are well visible in my space. I love 
them because they remind us that not all things are about rationality. 
Lovely that Swiss socks have been dragged into their realm, kind and 
much appreciated!

And yes, things are more complex and I fully agree that it's the 
features which matter, not the packet format encoding. So I hope that we 
can all leave our "Karl Lagerfeld sock design" aspiration behind us and 
talk features (how many toes etc ;-).

Well, there *is* a guy in the networking community labeling himself as 
"protocol stylist" .. Dr Seuss is everywhere it seems.

Happy new year, too! And best regards,
christian

On Wed, 7 Jan 2015, Mark Stapp wrote:

> issues are about what can be expressed, what features are necessary, and what 
> is a reasonable minimum set of primitives that allows us to experiment. This 
> ongoing discussion is hopefully making things more concrete and more 
> verifiable. And hopefully that may help clarify what works and what does not 
> - at least it seems so to me. And continuing to work out some common ground 
> rules lets us experiment together, rather than in parallel.
>
> Now as you may remember I am not a particular fan of socks, though I support 
> the right of each individual to choose for him/herself. Do you know Dr Seuss, 
> the childrens' book writer? Here's a little doggerel in that style:
>
> Dumb bits fits
> In socks' knits,
> Such soft socks
> Walk on rocks,
> Quick Basel fox,
> Switch Swiss socks!
> Signed Swiss socks?
> Such signed socks,
> Stuck in box!
>
> Cheers,
> Mark
>

---

From: Andrea Detti <[email-masked]>
Date: Thu, 08 Jan 2015 10:24:07 +0100

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.

I see a scalability problem with the ICN routing plane, 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.
In that case, prefix aggregation is hard and flat routing plane update 
is hard too.
Thus, I believe that including a routing info in a header filed of the 
Interest packet could be the plain old solution to scale routing (e.g. 
see "Scaling NDN Routing: Old Tale, New Design" paper).
For instance, routing info could be the AS number or other hierarchical 
name that is useful strictly for routing propose, rather than to 
identify the object. Forwarding engine can use routing info field if 
routing on object name fails, and if the routing info field is present.
Being a name, forwarding by routing info does not require another 
forwarding engine.

I know that routing info could appear as a "regression" respect to the 
"pure" idea of routing on object name. But what do we lose?. Caching? 
Likely no, since object name is however transported in the headers. 
Multicast by PIT? Likey no, since PIT can use object name too. 
Multi-source? Partially. Since a routing info is similar to a unicast 
locator, thus handle multi-source may be tricky but not impossible  
(e.g. with bloom filter, etc.). Security (content validity check) ? 
"Likely" not, signature can exclude the routing info. Architectural 
simplicity. Yes. We need a third party that resolves the routing info 
and this is the price to scalability.

This said, I wander if it is worth to think to a TLV for routing info.

Regards,

Andrea

On 01/06/2015 09:31 PM, Mark Stapp wrote:
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Mark Stapp <[email-masked]>
Date: Thu, 08 Jan 2015 11:19:35 -0500

> and wonder ICN community think about that. Especially with respect to

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 provided by mobile devices.  This framework could be the

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

---

From: <[email-masked]>
Date: Thu, 8 Jan 2015 17:00:40 +0000

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. 

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 <[email-masked]> wrote:

> 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.
> 
> 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
>

---

From: Andrea Detti <[email-masked]>
Date: Fri, 09 Jan 2015 11:30:22 +0100

> 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…

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

---

From: David Oran <[email-masked]>
Date: Fri, 9 Jan 2015 09:21:35 -0800

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 <[email-masked]> wrote:
> 
> 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”
> 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)”
> Hermans et. al,  2012 - Global source mobility in the content-centric networking architecture- “Separate namespaces for identifier and locators”.
> 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” 
> 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)”
>> 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 
>> <[email-masked]>
>>  wrote:
>> 
>> 
>>>

---

From: Andrea Detti <[email-masked]>
Date: Fri, 09 Jan 2015 19:26:25 +0100

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

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 9 Jan 2015 19:09:35 +0000

We don't have a draft on the packet proposal yet, but sharing the presentation prepared for discussion at next Tuesday's meeting, in which we include more considerations:

1. Multi-Protocol Support
2. Support for Large Payloads
3. Handling dynamism (mobility/migration etc.)
4. Handling Notifications
5. Handling Conversational traffic

Comments are welcome.

http://trac.tools.ietf.org/group/irtf/trac/attachment/wiki/icnrg/CCN-NDN-Packet-format-v1%207.pdf

Regards,
Ravi
-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Andrea Detti
Sent: Friday, January 09, 2015 10:26 AM
To: David Oran
Cc: [email-masked]
Subject: Re: [icnrg] updated cisco packet format draft

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.

I do not know :-)

Andrea

On 01/09/2015 06:21 PM, David Oran wrote:
> 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.
>
>
>>> 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.
>>>
>> 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"
>> 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".
>> 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"
>> 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)"
>>> It is not mandatory that applications do this - some data might rightly belong in the name.
>>>

---

From: IKRAM UDDIN <[email-masked]>
Date: Sun, 11 Jan 2015 08:08:23 +0000 (UTC)

Dear Mark,

As you have mentioned that "Using this method relieves the forwarding plane from having to process and store in the PIT large names that make no difference in routing", so I'm a little bit confused; if some names are already stored in the PIT then those names will be ignored or what will happen to them?
Regards,
Ikram Ud Din
InterNetworks Research Laboratory,Graduate School of Arts and Sciences,Universiti Utara Malaysia. 

     On Saturday, January 10, 2015 3:16 AM, Ravi Ravindran <[email-masked]> wrote:

Comments are welcome.

Regards,
Ravi
-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Andrea Detti
Sent: Friday, January 09, 2015 10:26 AM
To: David Oran
Cc: [email-masked]
Subject: Re: [icnrg] updated cisco packet format draft

I do not know :-)

Andrea