Subject: [icnrg] Some thoughts about the methodology draft

From: Grieco <[email-masked]>
Date: Thu, 6 Mar 2014 14:03:31 +0000

Dear Kostas, and all,

I went through the methodology draft and I just have a couple of remarks.

When we speak about methodology we need to specify what the methodology is meant for.

It seems that the draft has a very ambitious goal: to provide guidlines to drive the performance evaluation of ICN architectures. 

The point is that, besides some basic common points, nowadays we already have many different kinds of architectures so that it could be useful to describe the Minimum set of KPI to investigate for each of them. Of course, only a subset of them will be shared among the different ICN architectures.

Another point referes to the need to investigate both data plane and control plane. While on the data plane, KPIs for different architectures could be the same, on the control plane this is not the case. If I am a new researcher on this topic what should I look for when evaluating the control plane and/or the data plane of ICN-A or ICN-B and so on ?

To the best of my understanding, it seems that the draft only partially answers this basic yet fundamental question.

Cheers and thanks in advance for your attention

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

---

From: Kostas Pentikousis <[email-masked]>
Date: Thu, 6 Mar 2014 22:25:29 +0100

Hi Alfredo

| I went through the methodology draft and I just have a couple of remarks.
|

Many thanks for sharing your thoughts. We need to have this discussion on the mailing list if we want the draft to advance in a faster pace.

| When we speak about methodology we need to specify what the methodology is meant for.
|
| It seems that the draft has a very ambitious goal: to provide guidlines to drive the
| performance evaluation of ICN architectures. 

I'm not sure we all agree on this however, and it's good to have this discussion as we aim for at least one update before Toronto. Right now the draft surveys evaluation tools and makes some suggestions, which need to be further elaborated and refined, as we agreed in the meeting earlier this week.

| The point is that, besides some basic common points, nowadays we already have many
| different kinds of architectures so that it could be useful to describe the Minimum set
| of KPI to investigate for each of them. Of course, only a subset of them will be shared
| among the different ICN architectures.

Would you like to give an example of this for your favorite ICN approach? Section 2.4 covers this to some degree by summarizing the metrics used in earlier studies. Perhaps we could extend it based on your (and others') input.

| Another point referes to the need to investigate both data plane and control plane. While
| on the data plane, KPIs for different architectures could be the same, on the control 
| plane this is not the case. If I am a new researcher on this topic what should I look for
| when evaluating the control plane and/or the data plane of ICN-A or ICN-B and so on ?

ICN control/data plane separation is a pertinent topic, of course. Any pointers to the literature where this aspect is considered as part of an evaluation will be much appreciated.

One an another note, section 2.1.5 (http://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-00#section-2.1.5) is very generic right now: it basically describes large testbed infrastructures but does not discuss experience with using such testbeds to evaluate ICN. I think we need to get some more details about ICN large-scale testing; any pointers much appreciated.

Best regards,

Kostas

---

From: Alfredo Grieco <[email-masked]>
Date: Sat, 08 Mar 2014 17:13:27 +0100

Hi Kostas, and all,

it seems to me that the draft covers quite well evaluation issues 
related to the data plane. In this case, parameters are clear and a new 
starting researcher could find solid guidelines to drive his activities.

At the same time, the control plane seems to be totally uncovered. It is 
not only matter of new references but a new section could be required. I 
am not an expert of control plane. I was trying to figure out how to 
deal with control plane issues in ICN and did not find answers in the 
draft. That's the reason of my feedback.

Many thanks for the attention.

cheers

Alfredo

-- 
Luigi Alfredo Grieco, PhD
Assistant Professor
Dep. of Electrical and Information Engineering (DEI)
Politecnico di Bari
Via Orabona, 4
70125 - Bari - Italy
Phone: +39 080 5963 911
url: telematics.poliba.it
mail: [email-masked]

---

From: David R Oran <[email-masked]>
Date: Sat, 8 Mar 2014 10:14:13 -0800

It isn’t clear to me that most ICNs have separate discernible control and data planes.
Could somebody clue me in?

On Mar 8, 2014, at 8:13 AM, Alfredo Grieco <[email-masked]> wrote:

> Hi Kostas, and all,
> 
> it seems to me that the draft covers quite well evaluation issues related to the data plane. In this case, parameters are clear and a new starting researcher could find solid guidelines to drive his activities.
> 
> At the same time, the control plane seems to be totally uncovered. It is not only matter of new references but a new section could be required. I am not an expert of control plane. I was trying to figure out how to deal with control plane issues in ICN and did not find answers in the draft. That's the reason of my feedback.
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Alfredo Grieco <[email-masked]>
Date: Mon, 10 Mar 2014 11:06:32 +0100

Dear Spiros,

here are some few questions related to the control plane:

- how much it cost to handle name prefix announcements ?
- how is it possible to handle announcements in mobile networks ?
- how is it possible to internetwork IP and ICN networks ? How much it 
cost ?
- can we deploy a parallel resolution system to assist ICN routers ?
- can we virtualize ICN router to ease their management ?
- how to answer all previous questions in different ICN systems ?

The most of the literature on the data plane simply assume that prefixes 
have been already announced. But, in reality, this could be not that simple.

I remark (once again) that I am not a specialist of control plane, so 
take my questions as those of a beginner that needs to understand.

cheers and thanks for your attention

Alfredo

Il 3/10/2014 10:47 AM, Spiros Spirou ha scritto:
> Hi Alfredo,
>
> On 8/3/2014 6:13 μμ, Alfredo Grieco wrote:
>
> Would it be possible to provide an example of what you would like to 
> see in the draft in relation to the control plane? What might be a 
> control plane KPI?
>
> Thanks,
>
> Spiros
>

---

From: Spiros Spirou <[email-masked]>
Date: Mon, 10 Mar 2014 11:47:35 +0200

Hi Alfredo,

> draft. That's the reason of my feedback.

Would it be possible to provide an example of what you would like to see 
in the draft in relation to the control plane? What might be a control 
plane KPI?

Thanks,

Spiros

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 10 Mar 2014 14:04:01 +0000

Maybe this has something to do with the explicit publications in a pub/sub model.
In CNN, there is may not be separate messaging (control), to make a data available, isn't there.

- Hannu 

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of ext David R Oran
Sent: Saturday, March 08, 2014 8:14 PM
To: Alfredo Grieco
Cc: Kostas Pentikousis; [email-masked]
Subject: Re: [icnrg] Some thoughts about the methodology draft

It isn't clear to me that most ICNs have separate discernible control and data planes.
Could somebody clue me in?

---

From: David R Oran <[email-masked]>
Date: Mon, 10 Mar 2014 07:48:51 -0700

> In CNN, there is may not be separate messaging (control), to make a data available, isn't there.
Sure, there may be. I guess I have not found the control plane / data plane taxonomy terribly useful in analyzing or architecting systems, or in measuring them. There are protocols that operate on differing timescales, with differing speed and scalability properties. Some need to run at wire speed (e.g. BFD, Ethernet OAM). Some need to mimic the behavior of the data-carrying packets but travel separately (e.g. ICMP). Some are transparent to intermediaries (e.g. SNMP); some are processed by intermediaries (e.g. RSVP). Some instantiate state that affects the handling of packets carrying data (e.g. routing); some do not (e.g. Netflow). Sometimes they are embedded in the data-carrying protocol (e.g. RTP header extensions). Sometimes they are not (e.g. RTCP). Sometimes they are layered “on top of” the protocol carrying user data (e.g. OSPF). Sometime they are parallel and run on the lower layer service (e.g. ISIS).

The particulars seem to matter a whole lot more than the taxonomy of what’s control and what’s data.

DaveO.

---

From: Dirk Kutscher <[email-masked]>
Date: Mon, 10 Mar 2014 15:26:27 +0000

Hi Alfredo,

Thanks -- I'd say these are all good questions in one or the other ICN context and would propose to discuss them without introducing an a-priori architectural control/user plane split.

"Control plane" is unfortunately an overloaded term. Older networks (SS7...) used to have a separate control plane, and one of IP's features was that it can use the same network for "user" and "control" plane communication.

When it comes to router/switch implementations, they of course have a "data plane" and a "control plane". SDN refers to these planes when it talks about "control plane", i.e., OpenFlow for example is about moving the control plane out of network elements, logically centralize it and use it for programming a network of elements.

Some of the things you mentioned (virtualize yes/no) are probably rather implementation-specific, so we should be sure to focus on ICN-intrinsic topics ("KPIs").

In that context, we touched upon network management in London (and previously). A good topic for ICNRG could be to figure out the functions that absolutely need specific management interfaces/protocols in ICN.

A second question (also currently discussed) could be: is it possible to build an ICN-based management framework for them?

Best regards,
Dirk

> From: icnrg [mailto:[email-masked]] On Behalf Of Alfredo Grieco
> Sent: Montag, 10. März 2014 11:07
> To: [email-masked]
> Cc: [email-masked]
> - how is it possible to internetwork IP and ICN networks ? How much it cost ?
> I remark (once again) that I am not a specialist of control plane, so take my
> questions as those of a beginner that needs to understand.
> 
> >> At the same time, the control plane seems to be totally uncovered. It
> >> is not only matter of new references but a new section could be
> >> required. I am not an expert of control plane. I was trying to figure
> >> out how to deal with control plane issues in ICN and did not find
> >> answers in the draft. That's the reason of my feedback.
> >
> Dep. of Electrical and Information Engineering (DEI) Politecnico di Bari Via
> Orabona, 4
> 70125 - Bari - Italy
> Phone: +39 080 5963 911

---

From: <[email-masked]>
Date: Mon, 10 Mar 2014 15:33:33 +0000

I agree that the devil is in the details for what’s a control packet.  We really should come up with concrete use cases for a new packet type before introducing one.  In CCN, packet types imply a specific node behavior: Interests modify the PIT and follow the FIB, Content Objects follow the PIT and destroy the state.  If there is need for a different behavior, then we should have a different packet type.

Personally, I believe there is use for a link-local control packet for use, among other things, by routing protocols, bridging protocols, VRRP, discovery, etc..  In these protocols, pushing data in an Interest is poor, because one does not expect a Content Object response so the PIT state is wasted.  Doing a pull model, from the examples I’ve seen, is also often wasteful or requires link-specific hacks.

I’m less certain about multi-hop network control packets begin different than Interest/Object conversations.

That all said, I think the use cases need to be spelled out in some detail so we get the proper generalization of what a control packet is in CCN.   I’d rather it not be the kitchen sink of everything an Interest/Content Object is not.  One also needs to consider if the new behavior is a result of naively mapping an existing protocol on to CCN, or if there’s a better CCN way of doing it.

Marc

---

From: Daniel Corujo <[email-masked]>
Date: Mon, 10 Mar 2014 15:39:32 +0000

Dear all,

This is (the two questions placed by Dirk), in fact, the essence of what we have been trying to capture in the ICN Management Considerations draft. It currently has progressed in two aspects: ICN-manageable aspects, and ICN as a management tool. In the past, it touched quite a bit on ICN manageable functions as well. However, the problem back then (as now), is that we are limited to the contributions about these topics, as well as to the actua research that fundaments those contributions.

I think that we tried to grasp the possibilities and usefulness of a ICN management framework in a previous work (http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=&arnumber=6384449). However (in respect to Marc’s email), the work relied on basic Interest/Data changes to allow the management procedures to occur, instead of applying a specific purpose packet.

Finally, an important factor, is that it is important to consider that different ICN instantiations might lead to different management requirements and, despite the ample availability of considerations about CCN, and to some extent, NetInf, contributes about others should also be addressed.

Best regards,

Daniel Corujo, Ph.D.														
http://re.vu/dcorujo
Advanced Telecommunications and Networks Group - http://atnog.av.it.pt
Follow us - @ATNoG_ITAv

---

From: "Trossen, Dirk" <[email-masked]>
Date: Mon, 10 Mar 2014 12:25:15 -0400

...hmm, how do the FIBs get into the routers? 

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Flinck, Hannu
(NSN - FI/Espoo)
Sent: 10 March 2014 14:04
To: ext David R Oran; Alfredo Grieco
Cc: Kostas Pentikousis; [email-masked]
Subject: Re: [icnrg] Some thoughts about the methodology draft

Maybe this has something to do with the explicit publications in a
pub/sub model.
In CNN, there is may not be separate messaging (control), to make a data
available, isn't there.

- Hannu 

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of ext David R
Oran
Sent: Saturday, March 08, 2014 8:14 PM
To: Alfredo Grieco
Cc: Kostas Pentikousis; [email-masked]
Subject: Re: [icnrg] Some thoughts about the methodology draft

It isn't clear to me that most ICNs have separate discernible control
and data planes.
Could somebody clue me in?

>> Many thanks for sharing your thoughts. We need to have this
discussion on the mailing list if we want the draft to advance in a
faster pace.
>> | It seems that the draft has a very ambitious goal: to provide 
>> | guidlines to drive the performance evaluation of ICN architectures.
>> 
>> I'm not sure we all agree on this however, and it's good to have this
discussion as we aim for at least one update before Toronto. Right now
the draft surveys evaluation tools and makes some suggestions, which
need to be further elaborated and refined, as we agreed in the meeting
earlier this week.
>> 
>> | The point is that, besides some basic common points, nowadays we 
>> | already have many different kinds of architectures so that it could

>> | be useful to describe the Minimum set of KPI to investigate for 
>> | each of them. Of course, only a subset of them will be shared among
the different ICN architectures.
>> 
>> Would you like to give an example of this for your favorite ICN
approach? Section 2.4 covers this to some degree by summarizing the
metrics used in earlier studies. Perhaps we could extend it based on
your (and others') input.
>> 
>> | Another point referes to the need to investigate both data plane 
>> | and control plane. While on the data plane, KPIs for different 
>> | architectures could be the same, on the control plane this is not 
>> | the case. If I am a new researcher on this topic what should I look
for when evaluating the control plane and/or the data plane of ICN-A or
ICN-B and so on ?
>> 
>> ICN control/data plane separation is a pertinent topic, of course.
Any pointers to the literature where this aspect is considered as part
of an evaluation will be much appreciated.
>> 
>> One an another note, section 2.1.5
(http://tools.ietf.org/html/draft-irtf-icnrg-evaluation-methodology-00#s
ection-2.1.5) is very generic right now: it basically describes large
testbed infrastructures but does not discuss experience with using such
testbeds to evaluate ICN. I think we need to get some more details about
ICN large-scale testing; any pointers much appreciated.
> Dep. of Electrical and Information Engineering (DEI) Politecnico di 
> Bari Via Orabona, 4
> 70125 - Bari - Italy
> Phone: +39 080 5963 911

 

Dirk Trossen 
Principal Engineer
InterDigital UK, Inc.
Shoreditch Business Center
64 Great Eastern Street
London, EC2A 3QR
T: +44 20 7749 9178
[email-masked]
www.InterDigital.com

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

---

From: George Xylomenos <[email-masked]>
Date: Mon, 10 Mar 2014 19:17:08 +0200

The FIBs may get into the routers via OSPF-N (or an equivalent 
protocol), so the question becomes how do you announce your ability to 
serve part of the CCN/NDN namespace to your local node. You need either 
a third network primitive (beyond Interest/Data), or a local primitive 
(syscall like) for announcing this. This is not the same as announcing 
network prefixes for IP routing, since you need to do it dynamically and 
with many namespace prefixes, so it cannot be purely be based on 
configuration files, unless if we want to bring the 
location-identification binding right back into ICN. I would argue that 
for practical purposes (specifically: to reduce the number of nodes 
running the routing protocol) you need a network primitive rather than a 
local primitive, which would be the counterpart of the advertise 
messages in pub/sub systems. I think we have had this exact discussion 
in a Dagstuhl seminar in a breakout group with Nacho last year.

On the other hand, I agree with Dave O. that the control/data plane 
distinction has not proved very useful in the IP world. In telephone 
networks, as Dirk K. pointed out, the distinction was clear (SS7 even 
used a different packet network to control circuit switching, it cannot 
get any clearer than that!) and in ATM it was decreed by the great 
powers what was in the control, management and data planes. But even if 
we settle on what the control plane is in IP (not that easy, but maybe 
doable), this may not make the same sense in ICN. Routing messages are 
easy, but is the pull message (Interest/Subscribe) before a 
Data/Publication message in the control plane? Is the Unnamed in ICN - 
Advertise in PURSUIT message in the control plane?

George X.

---

From: "Trossen, Dirk" <[email-masked]>
Date: Mon, 10 Mar 2014 13:26:10 -0400

Indeed, the division of control/data makes little sense since it needs an agreement what is 'controlled' (namespace, routing resources, caching resources, ...). For that reason, PURSUIT introduced a particular functional separation along the lines of demand/supply match, resource coordination and bit transfer - not to say that these are the only functions (if you think of management, for instance). 

Dirk
P.S.: my comment was mainly related to Hannu's comment that no messaging was required to make data available - surely OSPF-N qualifies as such messaging that is necessary to get the FIB entries into the routers ;-) 

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of George Xylomenos
Sent: 10 March 2014 17:17
To: [email-masked]
Subject: Re: [icnrg] Some thoughts about the methodology draft

The FIBs may get into the routers via OSPF-N (or an equivalent protocol), so the question becomes how do you announce your ability to serve part of the CCN/NDN namespace to your local node. You need either a third network primitive (beyond Interest/Data), or a local primitive (syscall like) for announcing this. This is not the same as announcing network prefixes for IP routing, since you need to do it dynamically and with many namespace prefixes, so it cannot be purely be based on configuration files, unless if we want to bring the location-identification binding right back into ICN. I would argue that for practical purposes (specifically: to reduce the number of nodes running the routing protocol) you need a network primitive rather than a local primitive, which would be the counterpart of the advertise messages in pub/sub systems. I think we have had this exact discussion in a Dagstuhl seminar in a breakout group with Nacho last year.

On the other hand, I agree with Dave O. that the control/data plane distinction has not proved very useful in the IP world. In telephone networks, as Dirk K. pointed out, the distinction was clear (SS7 even used a different packet network to control circuit switching, it cannot get any clearer than that!) and in ATM it was decreed by the great powers what was in the control, management and data planes. But even if we settle on what the control plane is in IP (not that easy, but maybe doable), this may not make the same sense in ICN. Routing messages are easy, but is the pull message (Interest/Subscribe) before a Data/Publication message in the control plane? Is the Unnamed in ICN - Advertise in PURSUIT message in the control plane?

George X.

---

From: Alfredo Grieco <[email-masked]>
Date: Mon, 10 Mar 2014 18:52:24 +0100

Hi all,

thanks for your thoughtful and generous answers.

We can also avoid to explicitly use the terms "control plane" and "data 
plane", but, talking about CCN/NDN, for example, we have much more that 
Interest and Data handshakes.
1) Before sending an Interest you need to know the name of the content.
2) To know the name of the content you need to call a kind of ICN-google 
(whose name is standardized... hopefully)
3) Once you know the name you send an Interest but (in the meantime) you 
have to hope that the FIB is populated (e.g., using OSPF-N) in such a 
way that ICN-routers become able to handle what you are looking for, 
otherwise you need to search the path using some algorithms that run at 
the strategy layer.
4) Catalogues are dynamic, so that announcements could introduce some 
overhead depending on how much you aggregate names and on the frequency 
of updates (expiry time).
5) the routing algorith that run at the strategy layer may depeds on 
some parameters that need to be tuned and adjusted

In most of articles we reference in the draft, steps 1)-5) are simply 
neglected assuming an ideal CCN/NDN. Indeed, from the correct and 
scalable implementation of steps 1)-5) it depends the actual success of 
CCN/NDN.

The same applies (with different terms and meanings) to different ICN 
architectures.

If we do not want to introduce a separation between data and controll 
planes, we need at least to define how to evaluate steps 1)-5) otherwise 
we have a "partial-evaluation-methodology-draft" instead of an 
"evaluation-methodology-draft".

Having said that, I have no idea to answer the questions I raise :-)

cheers

Alfredo

---

From: Börje Ohlman <[email-masked]>
Date: Mon, 10 Mar 2014 18:18:07 +0000

To continue the retrospective one can note that the reason SS7 was introduced was that the previous inband control signaling made it easy for end-users to manipulate the network. (You could set up calls by whistling, or buying  a blue box from Steve Jobs, and thereby call for free).
We probably should give some thought to which mechanisms we need to have to have to control who can send control signaling. Maybe that could be a definition of control signaling, i.e. signaling/messages that need to be authorized by the network operator.

Having said that I think we should take care not to get stuck in definitions discussions unless we see a clear purpose with it. I would not like to end up in the type of discussion about the difference between what is the difference between control and management that they have in the SDNRG.

	Börje

---

From: David R Oran <[email-masked]>
Date: Mon, 10 Mar 2014 13:56:38 -0700

> To continue the retrospective one can note that the reason SS7 was introduced was that the previous inband control signaling made it easy for end-users to manipulate the network. (You could set up…
Ah yes, security by physical separation or Layer 0/1 demultiplexing…

> We probably should give some thought to which mechanisms we need to have to have to control who can send control signaling. Maybe that could be a definition of control signaling, i.e. signaling/mes…
So, I’m in favor of treating all protocols as susceptible to attack and am skeptical of treating “control plane” or “management” protocol any differently. If you have solid cryptographic authentication and role-based access control you are on solid ground. If you don’t in today’s world you’re toast.

> Having said that I think we should take care not to get stuck in definitions discussions unless we see a clear purpose with it. I would not like to end up in the type of discussion about the differ…
Amen

---

From: MUSCARIELLO Luca IMT/OLN <[email-masked]>
Date: Tue, 11 Mar 2014 08:21:51 +0100

On 03/10/2014 04:33 PM, [email-masked] wrote:
> I agree that the devil is in the details for what's a control packet. 
>  We really should come up with concrete use cases for a new packet 
> type before introducing one.  In CCN, packet types imply a specific 
> node behavior: Interests modify the PIT and follow the FIB, Content 
> Objects follow the PIT and destroy the state.  If there is need for a 
> different behavior, then we should have a different packet type.

+1

>
> Personally, I believe there is use for a link-local control packet for 
> use, among other things, by routing protocols, bridging protocols, 
> VRRP, discovery, etc..  In these protocols, pushing data in an 
> Interest is poor, because one does not expect a Content Object 
> response so the PIT state is wasted.  Doing a pull model, from the 
> examples I've seen, is also often wasteful or requires link-specific 
> hacks.

IMHO, if it is possible to optimize the link with no additional control 
packets that would be better.
If a new protocol really requires that new control packet, I see it as 
optional and not mandatory,
unless one proves that protocol is the best solution with no drawbacks 
whatsoever.
In this latter case that packet would become part of the structural 
design of the system.

This is actually in line to what you write below; and I agree.

>
> That all said, I think the use cases need to be spelled out in some 
> detail so we get the proper generalization of what a control packet is 
> in CCN.   I'd rather it not be the kitchen sink of everything an 
> Interest/Content Object is not.  One also needs to consider if the new 
> behavior is a result of naively mapping an existing protocol on to 
> CCN, or if there's a better CCN way of doing it.
>
> Marc
>
> On Mar 10, 2014, at 7:48 AM, David R Oran <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>
>> On Mar 10, 2014, at 7:04 AM, Flinck, Hannu (NSN - FI/Espoo) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Sure, there may be. I guess I have not found the control plane / data 
>> plane taxonomy terribly useful in analyzing or architecting systems, 
>> or in measuring them. There are protocols that operate on differing 
>> timescales, with differing speed and scalability properties. Some 
>> need to run at wire speed (e.g. BFD, Ethernet OAM). Some need to 
>> mimic the behavior of the data-carrying packets but travel separately 
>> (e.g. ICMP). Some are transparent to intermediaries (e.g. SNMP); some 
>> are processed by intermediaries (e.g. RSVP). Some instantiate state 
>> that affects the handling of packets carrying data (e.g. routing); 
>> some do not (e.g. Netflow). Sometimes they are embedded in the 
>> data-carrying protocol (e.g. RTP header extensions). Sometimes they 
>> are not (e.g. RTCP). Sometimes they are layered "on top of" the 
>> protocol carrying user data (e.g. OSPF). Sometime they are parallel 
>> and run on the lower layer service (e.g. ISIS).
>>
>> The particulars seem to matter a whole lot more than the taxonomy of 
>> what's control and what's data.
>>
>> DaveO.
>>
>>
>>> - Hannu
>>>
>>> Cc: Kostas Pentikousis; [email-masked] <mailto:[email-masked]>
>>> On Mar 8, 2014, at 8:13 AM, Alfredo Grieco <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> Hi Kostas, and all,
>>>>
>>>> related to the data plane. In this case, parameters are clear and a 
>>>> new starting researcher could find solid guidelines to drive his 
>>>> activities.
>>>>
>>>> At the same time, the control plane seems to be totally uncovered. 
>>>> It is not only matter of new references but a new section could be 
>>>> required. I am not an expert of control plane. I was trying to 
>>>> figure out how to deal with control plane issues in ICN and did not 
>>>> find answers in the draft. That's the reason of my feedback.
>>>>

---

From: "GALLO, Massimo (Massimo)" <[email-masked]>
Date: Tue, 11 Mar 2014 13:44:17 +0000

I agree that the introduction of a new packet type should be motivated with concrete use cases.
The question that needs to be addressed is: are Interest and Content Object (in CCN) enough to implement every operation needed by the control plane?

As Mark said, a new packet type should be introduced if and only if it requires a specific node behaviour.  I think that the distribution of FIB entries among network routers is a good example (typical control plane operation). However all the implications of the introduction of a new packet type should be analysed properly (i.e. security).

Max
________________________________
From: icnrg [[email-masked]] on behalf of MUSCARIELLO Luca IMT/OLN [[email-masked]]
Sent: Tuesday, March 11, 2014 8:21 AM
To: [email-masked]
Cc: icnrg
Subject: Re: [icnrg] Some thoughts about the methodology draft

On 03/10/2014 04:33 PM, [email-masked]<mailto:[email-masked]> wrote:
I agree that the devil is in the details for what’s a control packet.  We really should come up with concrete use cases for a new packet type before introducing one.  In CCN, packet types imply a specific node behavior: Interests modify the PIT and follow the FIB, Content Objects follow the PIT and destroy the state.  If there is need for a different behavior, then we should have a different packet type.

+1

IMHO, if it is possible to optimize the link with no additional control packets that would be better.
If a new protocol really requires that new control packet, I see it as optional and not mandatory,
unless one proves that protocol is the best solution with no drawbacks whatsoever.
In this latter case that packet would become part of the structural design of the system.

Marc

On Mar 10, 2014, at 7:48 AM, David R Oran <[email-masked]<mailto:[email-masked]>> wrote:

On Mar 10, 2014, at 7:04 AM, Flinck, Hannu (NSN - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:

DaveO.

- Hannu

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of ext David R Oran
Sent: Saturday, March 08, 2014 8:14 PM
To: Alfredo Grieco
Cc: Kostas Pentikousis; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Some thoughts about the methodology draft

On Mar 8, 2014, at 8:13 AM, Alfredo Grieco <[email-masked]<mailto:[email-masked]>> wrote:

Hi Kostas, and all,

cheers

Alfredo