ICNRG interim meeting minutes

Saturday, 27 September 2014, Paris, France


First morning session


All three Chairs present; ~50 people in the room

- NOTE-takers recruited

- Agenda bashing (no changes)

- Last item of the day will be open discussion about take-aways from the

conference.   What insights valuable for ICNRG or any new items that

should be taken up.

- Also: Folks leaving early please give chairs their views on whether

to meet in Honolulu; needs to be decided in the next couple of days.


ICN and Video Distribution - Eiichi Muramoto, Panasonic

"Consumer Driven Adaptive Rate Control for Real-time Video Streaming


Target is at the "live" (=buffering intolerant) end of the spectrum.

Goal: less than 200 msec delay.

Examples: security camera, real-time tracking, with multiple users

accessing sources. RTT fairness is important!

Interest-data RTT variation caused by (i) data coming from different

sources; (ii) congestion, queueing (as in current Internet).

Proposed method: measure RTT on each data packet; cache average RTT in

each short period, control interest rate based on AvgRTT.  

[Q: Dave O - what's the increase exponent? 0.5=square root? yes.]

Basic idea: distinguish between source change and congestion by

suddenness of change.]

Single period increase/decrease -> assume source change.

Several consecutive increase/decrease -> infer congestion and adjust rate.

NDNSim evaluation.  Comparison vs. AIMD: proposed method is more

stable in various RTT, with lower delay.

Note: method not TCP-friendly

Evaluation of fairness: consumers gain same t'put, vs. AIMD where gain

is inversely proportional to RTT.

Evaluation on multi-bottleneck topology: good fairness, adapts to

smallest bottleneck.

UCLA video implementation.

Many Q's about parameters, how "consecutive" is defined, relationship

between buffers and RTT.  Where were caches?  Did you use the RED

queue in the simulator?  Are you aware of other work that shows

indicates that adapting according to RTT is hard?

Are you sure this is stable? (Answer to the

last seems to be no.)


Adeel Malik, Ericsson

Applicability and Tradeoffs of ICN for Efficient IoT


Goal: see how well ICN fits for IoT, what are challenges.  Try to

avoid introducing iot-specific architectural challenges in ICN.

Good fits: data-orientation, caching, sender-receiver decoupling

Challenges: control/manage devices, names could be larger than data,

dynamic data, security of real-time data

Design choices w/ no changes to ICN

  - device actuation and control: use ICN w/ existing protocols

  - how to name aggregated information (e.g. aggregated sensor readings)

   -- have known or deducible names

  - Immutable atomic data units vs. dynamic data

   -- model as a stream of immutable data units; "latest" name is deducible

      (e.g., from timestamp)

  - handling actuators - state as data object

   -- actuator has to poll for desired state

  - don't force constrained IoT devices to act as intermediate ICN nodes

   -- but they may store their own content

Dave Oran: what if you have a mesh network?  Yes, then you must have

nodes forward.

Ralph Droms: it's an important problem. It's more about

outing/fwding the interests, rather than data.

Börje: usually here we are talking about wireless; we should

remember that radios are naturally broadcast when we design ICN.

Dave O: Broadcast is seductive, but all nodes

have to be awake simultaneously for it to work.

Börje: yes, but we still need to take this back, e.g., to 5G

discussions - if we someday have very low-power radios that

are always on, things will look different.

George Polyzos: we should give proxies a more prominent role.  Scatter

 them throughout the network, use them for expensive operations.

Adeel: my statement might have been a bit aggressive. (:-)

George: but we should not accept the status quo either.

Dirk: instead of mandating proxies, we should discuss the options.

   Should that be true only for ICN?  Hybrid solution with Inet?

   We shouldn't mandate a proxy-only soln.

Mark Stapp: it's not either/or.  It's really a hybrid.  Some nodes

   are well-connected (or on). There will be some mix of managed and

   low-powered devices.


Ralph: There are many different use cases.  Example: sometimes nodes

   are low-power but fixed.  May need different strategy layers for

   different contexts.


Jörg Ott: The IETF is building IoT extensions for the Internet protos.  We

   should see this presentation as a starting point, which doesn't

   discount other options.

 - Object security - should be handled above ICN layer.

Ralph: re security: you don't have to have all the smarts in the

   node. Node can send the data and let somebody else worry about

   access control, other policy aspects.

Mark: you didn't mention the possibility of sending sensor data in

   interest messages.  I want to keep making the pitch for being able

   to do that.  "Route it to the more powerful object" seems like a

   viable model.

[Presentation resumes]

Design choices - where additions/changes to ICN would improve efficiency

  - Importance of time - may need extensions (metadata) to represent


  - Pull and push - want push for real-time, triggers, alarms.

     both should be supported.  But who defines the trigger conditions?

Dave O: there are subtleties when you combine push and pull. It would

  be good to have real use cases.  If you decide you need push to get

  things out quickly, you lose caching.  If data is generated by the guy

  sending the interest, the security model is cockeyed.  May be necessary to

  send the data you would have sent if it had been polled for.

  There's a real opportunity for interesting work here.

Ralph: opportunistic caching may not be useful in this case, but

  "architected caching" may be more useful, where it (cache) is explicitly


Felix : Suggest to look at what the Node.js guys did with their API

  for stream processing. It may be useful.

Manolis: Isn't this pretty application-oriented? What's important to

  the network is what is forwarded when...

Ralph: there is a question here: do you model this as one eternal

  object that emits chunks periodically, or is each sensor reading a

  different object?  Time series - thermostat vs parking meters, they

  are different things.

Paul Polakos[?]: when we talk about pushing and pulling, we may have different

  ideas of "push" - I think it implies someone is listening, else it's

  just not useful.

Mark Mosko: one way of getting real-time updates is to send an interest

  with very long lifetime, sits in the PIT at the sensor for long

  time, whenever there's new data it goes outs. (Not that he thinks

  that's a good idea...) 

 - optional Meta Data - for efficiency reasons, delivering metadata

   should be optional.

Dirk: the draft was really nice.  Re: efficiency - does it make

  sense to think about implementation efficiency, simplifying the

  stack etc. a la RIOT?

Adeel: not sure, hadn't thought about being that specific.

Ralph: what about operational considerations, e.g. overhead,

  configuration complexity?  That is another form of efficiency.

Dave: Maybe people who have ideas should contribute to the draft.

  My reading is that we should use this good discussion to move the

  discussion forward.


Ravi Ravindran, Huawei

ICN based Architecture for IoT - Requirements and Challenges


Looking at not just devices, but services and higher levels.

Multipoint to multipoint...

Draft was split to encourage participation, into challenges and


[Going through the draft]

Motivation: ICN-IoT could be one binding layer for lots of systems...

[summarizing the draft, see the slides.]

Legacy IoT systems - are very fragmented and siloed.  Small set of

pre-designated applications "Not something that fosters innovation"

State of the art is everything funnels to a server/gateway.

ICN allows to decouple service logic from data distribution logic.

Overlay approach - on IP is not really suitable.

Popular scenarios - smart grid, transportation, healthcare, education,


ICN Challenges:

Naming - constructible names, on-demand publishing.  Requesting data

not yet published.

Contributions to draft are welcome.

Dirk: meta-question.  This is an extensive effort.  What do we do with

  it? Have you considered exporting this to the hard core IoT people?  You

  are preaching ICN benefits to the choir here.  Any outside feedback?

Ravi: no. 

Börje: Dirk has a point.  If we want to reach out, if we think we have

  a better way of doing it we should sell our stuff to these people.

George P: what's the relationship with the previous draft?

Ravi: no connection.

Ralph: Lots of time spent in draft describing different application

  scenarios.  Are there common threads?

Ravi: that's why we put the requirements up front - many common things

  are provided by the basic ICN abstractions.  There are still

  area-specific challenges.  Last section is suposed to give the ICN

  perspective, but there are still things to be explored.

Dave O: this document tends to have a top-down approach to the area,

  more breadth than depth, which is good because it shows the shape.

  The other draft is more bottom-up: here are the real environments

  and what we have to deal with.  It may make sense to have both and

  work both bottom-up and top-down. 

Adeel: We had a section on design choices.  Are you willing to

  to suggest some choices?

Ravi: There is some work coming out that we think will cover that.

[Coffee Break]


Second morning session


CCN/NDN Packet Format, status update and discussion

Dave Oran intro:


Diego presenting "Update on experimental wire-speed packet format and comparison of different proposals”. Some key concepts/capabilities:


Nacho presented CCN 1.0 packet format. Some key concepts/capabilities:


Cisco - Mark Stapp

NDN - Alex Afanasyev




First afternoon session


/********** Industry-academic cooperation for the NDN project from NSF **********/


Dave talked a bit about the industry-academic cooperation for the NDN project.



/********** Scalable mobile backhauling via information-centric networking **********/


Presenter: Luca Muscariello


Luca: Packet forwarding is being done at 4000 packets per second

Dave: Is it graduate students doing that? :-)

Dave: So you are choking the links to achieve the same effect as a very high rate of packet forwarding?

Luca: Yes


Alex Afanasyev: What kind of CCN statistics?

Luca: Average hit miss etc. You can have per object statistics but that can slow down the system due to logging load.


Nacho: Is this the old CCN?

Luca: Yes


Mark: Did you try separating ICN with caching and ICN without caching. ICN without caching meaning multi-path.

Giovanna : Most of the gains come from multi-path actually.


Dave: Are you measuring all the way to the mobile?

Luca: Yes


Dave: Are you considering congestive losses here?

Luca: Yes


Börje: Are you doing ICN in the caches in eNodeB?

(Not able to capture the answer)


Dave: To get the same effect (multi-path) out of IP you would have to put a load-balancer in IP?

Giovanna : Dynamic load balancing would be impossible with IP in the mobile core.

Dave: Yes, because of the tunnels.


Ravi: Mobility is handled in L2 in mobile networks, right? You don't change your IP address.

Luca: It depends. (Not sure if that was really the answer)


Audience: Are you assuming that the budget of all caches is the same?

Luca: Yes

Audience: But in a few presentations in the conference earlier we saw that the benefits of edge caching can be more in certain cases.

Luca: (Not able to capture the answer)


Dirk: So when you say DPI you mean there is a transparent HTTP proxy?

Luca: Yes


Ravi: I dont see in the diagram that the UE talks ICN. Is it only HTTP that the UE talks?

Luca: Yes, ICN is transparent to the UE.

Ravi: How easy is that adaptation? Taking all HTTP traffic and putting it into ICN.

Luca: A number of adaptations are being done.



/********** Bloom Filter-based Flat Name Resolution System for ICN **********/


Presenter: Jungha Hong


Jeff Burke: What is the red line at the bottom in your diagram?

Jungha: That is a peering relationship.


Dave: Is adding or removing a locator equally expensive computationally as locator update?

Jungha: There is a difference. (Did not capture the rest)


Dave: Did you look at the scalability aspects of adding/removing/updating the locator?

Jungha: The scalability relates to the size of the bloom filter. Do you mean to talk about that?

Dave: Let's take is it offline.


No more questions or comments after the presentation.



/********** A distributed latency-aware caching mechanism for networks of caches **********/


Presenter: Leonce Mekinda


Audience: Have you tried to evaluate the signaling needed for your approach?

Leonce: There is no signaling. A node makes local decision based on the latency of the packet.


Dave: In your model it seemed like you had latencies in a restricted range. Not very high or very low latencies. Which means that this approach is not for high pressure points.

Leonce: (Did not capture the answer)


Dave: Since caching is being done based on latencies, that means that caches in Denver will be caching content from Japan rather than caching content from San Francisco

Leonce: It is probablistic. We take popularity into consideration. So that problem will not occur.


Dave: What about someone deliberately inflating latency so that their content is cached.

Leonce: That is a problem. But the problem is mitigated to some extent since popularity is taken into consideration.

Note: Orange has decided not to make the slides presented at this presentation public at this point in time.

[Coffee break]


Second afternoon session


Christian talk - Named functions

- Networking is full of name rewriting

- Network is full of term rewriting

- Modules rewrite

- Modules can be abstracted (higher level rewrite boxes, ping is composed of many rewrite boxes)

DaveO: Turing complete -> halting problem?

Christian: Not everything is solved. Just a view of networking.

KevinF: Timing problems?

Christian:  Some things are not possible from a theory perspective.  The arrogant formal theory viewpoint.

KevinF: It may not be a rich enough model

- CCN: rewrite box interests->content objects (I->CO)

- View the network as that type of box (interest->content object)

- Do all boxes look like the high level box (I->CO)?

DaveO: In costumer side, data does not arrive without an interest.  

KevinF: Rewriting system that is not order preserving? 

DaveO: If data can be produced before an interest arrives, that implies you know the name that will be used.  How does this map to rewriting?

KevinF: Is this an arbitrary rewriting system?

Christian: It’s a framework

- How much work is done in the box?  (or adjacent boxes)

- Interest with selectors could be rewritten for an environment without selectors

- Lambda calculus (expressions as inputs, results as outputs)

- NFN can emulate all ICNs

- NFN could translate from NDN to CCN.

KevinF: What’s the difference between NDlog and this?

NDlog was for configuration specification

NFN is for executing functions. More complex queries.

- Current approach, a name stays. We need to experiment changing that in the network.

- SQL does rewriting with builtin functions

- How much stuff can we bring into from Descriptor based systems?

- Named data has a constant name-to-object binding

- NFN has term rewriting

- Who can run on top of who?

DaveO: NDN only sees one hop in a computational chain.  (for example, requesting a video of a certain bit-rate).  

KevinF: Naming issues also exist in sender-based system.   (Send this to green people within 3 meters of point X)

DirkK: We should talk about whether NFN is above the ICN layer.

KenC: This might only focus on one part of the network. But it seems suitable mostly to lambda calculus.

FelixR:  Is NDN only a subset of NFN.

XXX: We should talk about explicitly exposing functions from the network. Not necessarily doing full lambda calculus.

XXX: Most of the packet formats expose the same information. We might need to expose a way to convert 1 to the other.

Leonce: RESTful system just RPCs like NFN

Christian: NFN has no side effects on the network.  RPCs an interesting thing to look at.

KenC: Not a lot got done with pure lambda calculus / LISP

JeffT: If you move discovery out of routers the discovery can do something more fancy, like run other functions.

JeffT: In REMAP we define a namespace, once defined, you want to query things in a different manner than the hierarchal namespace.

MarkS: That’s SQL!  -  We need constraints.

DirkK: What’s the NFN concept over the ICN concept.

Christian: Does every router need to do the same thing?

MarkS: A router that’s designed for throughput needs to do the correct thing when it sees traffic of certain type

Christian: Name doesn’t need to be the name used for networking

DaveO: It seems there’s a strong desire to collapse layers.    Route to places to compute stuff, return previous results without redoing computation, etc.  Is there a strong benefit to collapsing?

DaveO: I know what the worse case for forwarding is.  I don’t know what the arbitrary computation is if we collapse layers.  What do you lose by layering on top?

Nacho: CCN is trying to define what every node must do.

KevinF:  Nacho is too black and white.  You need to define middle boxes and things that are needed in some boxes.

MarkS: Transport functions are more logical to implement in network, but arbitrary functions are hard.  

MarkS: We can let the network expose some stuff.

<discussion discussion discussion>  = what is black and white

Nacho: CCN defines a minimum set, yes, it sets a line in the sand.  We decided not to do regular expressions for queries or attributed based naming.

DirkK: What are we defining on each layer? 

KevinF: Is it a layer or is it optional.

Nacho:  Caching is optional.

KevinF:  You seem to be looking at programable networks, and this is just how programable networks apply to ICN.

DirkK: There is interest in this topic from the group.

KevinF: You might even be able to form an RG.


IETF Honolulu discussion

Dirk - We could get a slot, potentially 2 slots if needed.

Dave - If we’re going, we should exploit the meeting.  Work on the packet format?  

Börje - Send suggestions to the list of what we want to talk about in Honolulu

Dirk going to Honolulu.

Potentially an interim meeting before Dallas for packet format.


Attendance list






Börje Ohlman

Borje.Ohlman a t ericsson.com


Diarmuid Collins

collindi a t tcd.ie


Dimitri Papadimitriou

dimitri.papadimitriou a t alcatel-lucent.com


Jeff Thompson

jefft0 a t remap.ucla.edu


Ravi Ravindran

ravi.ravindran a t huawei.com


George C. Polyzos

polyzos a t aueb.gr


Mayutan Arumaithurai

mayutan.arumaithurai a t gmail.com


Paul Duggan

dugganp4 a t tcd.ie


Mark Stapp

mjs a t cisco.com


Yong-Jin Park

yjp a t ieee.org


Luca Muscariello

luca.muscariello a t orange.com


Salah El Ayoubi

salaheddine.elayoubi a t orange.com


Léonce Mekinda

leonce.mekinda a t orange.com


Nacho (Ignacio) Solis

Ignacio.Solis a t parc.com


Glenn Scott

Glenn.Scott a t parc.com


Glenn Edens

Glenn.Edens a t parc.com


Marc Mosko

Marc.Mosko a t parc.com


Ersin Uzun

Ersin.Uzun a t parc.com


Andriana Ioannou

ioannoa a t scss.tcd.ie


Michele Tortelli

tortellimichele a t jp.panasonic.com


Eiichi Muramoto

muramoto.eiichi a t parc.com


Zeng Xuan

zeng.xuan a t orange.com


Claudio Imbrenda

claudio.imbrenda a t orange.com


Dave Oran

oran a t cisco.com


Jörg Ott

jo a t netlab.tkk.fi


Olov Schelén

olov.schelen a t ltu.se


Christian F. Tschudin

christian.tschudin a t unibas.ch


Christian Kreuzberger

christian.kreuzberger a t itec.aau.at


Daniel Posch

Daniel.Posch a t itec.aau.at


Jungha Hong

jhong a t etri.re.kr


Antonella Molinaro

antonella.molinaro a t gmail.com


Joo-Chul Kevin Lee

cms.rune a t orange.com


Adeel Malik

adeel.mohammad.malik a t ericsson.com


Giovanna Garofiglio

giovanna.carofiglio a t alcatel-lucent.com


Dirk Kutscher

dirk.kutscher a t neclab.eu


Diego Perino

diego.perino a t alcatel-lucent.com


Manolis Sifalakis

sifalakis.manos a t unibas.ch


Sergey Slovetsky

Sergey.Slovetskiy a t ericsson.com


Bursztynowski Dariusz - Korpo

Dariusz.Bursztynowski a t orange.com


Akira Ito

AIto a t us.fujitsu.com


Paul Polakos

ppolakos a t cisco.com


George Xylomenos

xgeorge a t aueb.gr


Andrea Araldo

andrea.araldo a t gmail.com


Thomas Schmidt

t.schmidt a t haw-hamburg.de


Matthias Wählisch

m.waehlisch a t fu-berlin.de


Cedric Adjih

cedric.adjih a t inria.fr


Gill Bilal

bilal.gill a t aalto.fi


Ralph Droms

rdroms a t cisco.com


Ken Calvert

calvert a t netlab.uky.edu



n.n a t dom.com