Minutes interim-2017-icnrg-03: Fri 09:00

Meeting Minutes Information-Centric Networking (icnrg) RG
Title Minutes interim-2017-icnrg-03: Fri 09:00
State Active
Other versions plain text
Last updated 2017-10-09

Meeting Minutes

 Session 1 - 09:00 to 10:30 AM
Note taker: Thiago Teixeira (UMass Amherst)

Borje introduces the meeting and the agenda. No questions or concerns.


Michael (MSA) gives a presentation about ICN-powered IoT and its requirements.
MSA performs maintenance in industrial plants where dangerous events may occur
at times (explosions, gas leaks, etc). The company developed a safety software
that provides a set of messages, such as alarms, man down, and other emergency
messages. The question to the audience is how ICN can provide a reliable
communication in this scenario? The company has deploy two schemes, with some
intermediate results. The schemes are Pub/Sub scheme for NDN and pyICN2mqtt,
which were presented in the demo session at ICN 2017. Currently, MSA is working
on how to identify problems and challenges in ICN management, using a ICN

Borje: Can you expand on the challenges?
Michael: Networks stacks, where the company does not have the manpower to
develop theirselves; security in this industrial scenario is another challenge.
Also, the push or pull paradigm (in emergency scenarios you might want to use a
push scheme).

Niels: Can you please clarify the  missions, or scenarios?
Michael: Describes that employees usually work a 8hrs shift, and the
tool/device that he or she worked on can report improvements or output. You
also have yearly maintenance, where the whole factory stops for a period and
instruments could report back to the management system.

Christian: How does the market look? Can other companies improve the quality of
the code? Michael: Other parties can improve the quality of the code and
improve the capabilities of the software. It is an opportunity for students to
come up with startups and provide services.

Marcel: What stack are you using in the moment?
Michael: Although Michael cannot give much details on the products that the
company is developing, he said that they use Android and other libraries.

Dirk: In terms of security and certification, are you aware of the requirements
in this direction? Michael: Although I'm not a certification expert, I believe
that some research can be done in this domain. On the other hand, we have some
in house solutions.


Mayutan and Dennis presented ICN in Mobile Edge Computing for connected
vehicles environments. The current latency for cloud based services is in the
order of 100 ms, which is a limitation for VANET scenarios. Mobile edge
computing (MEC) can be an solution to this problem. Research directions:
        •       Mobility: Consumer and producer mobility between road side
                Kostas: Why WLAN?
                Mayutan: Any technology can be used actually, including LTE and
                5G. Thomas: If we really want to migrate functions between RSUs
                and routing convergence is not fast enough considering car
                mobility. Mayutan: There's ongoing work on node mobility
                estimation that can address the issue of mobility. On the
                migration topic, we just started the discussion, but at some
                point you can migrate the function to a farther away RSU to
                cope with the traveling time vs. migration time. Jan: raises
                the questions of name resolution and mobility. Since we
                broadcast in VANET, do we really need names and name discovery?
                (communicating parts can pre-agree on a set of names) Dirk: It
                depends on the use case. In some applications you ask for named
                data, others you have neighbor discovery. Mayutan: For some
                information it makes sense to broadcast. Other scenarios, for
                example, several cars can be watching the same video, so you
                can make intelligent decisions on what packets to broadcast.
                Dirk: We have been debating this issue of neighbor discovery
                and different ways to perform this task.

        •       Caching: Prefetching popular content to RSU; Cache revocation;
        Monetization; Assurance;
                Jan: There's been a lot of work in CDN, proactive caching, and
                so on. The bottomline is that is very hard to beat LRU. In the
                average case LRU is better. Dave: - If you want application
                developers to individually develop applications, this notion
                that there's an application independent sort of god-like thing
                in the middle that figures out what for any given application
                is the important content, there's a  missing link. How does an
                application tell something centralized/global what the dynamics
                of the namespace look like? Second, this doesn't comport well
                in a completely decentralized solution. So we may need to think
                about how can you marry on demand caching, where some things
                are fetched dynamically, and then some kind of pre-fetching
                scheme that the application can provide. For example if
                somebody fetches a certain content, there is likelihood that
                this node fetches several other related contents is greater
                than the probability that they fetch some other thing.

     "I do not want to be the Least Recently Used person in an emergency" --
     Dave Oran

        •       Naming: more visibility to what is needed; Tradeoff between
        name description and performance; how to provide additional context

        •       Others - Security and privacy; data dissemination (push vs.
        pull); routing and forwarding (MEC or cloud)
     Marcel: comments about the concerns of putting computation at the edge and
     securing the physical device (RSU) Alberto: comments that depends on the
     computation you want to do on the data.

        •       Large scale data: the current prediction is that cars will
        generate a lot of data. How to deal with the increase in data


Michal presents about adapting ICN to Funtion Execution for Edge Computing
Dave suggests the use of thunk and label forwarding.
Smart contracts can be used as payments method.

Thomas: Public ledgers are slow.

Christian: Trust relies on Intel hardware. It's still much better than we have
today. Michal: Correct. Ken: Following up on that, the idea of downloading a
private key through a TLS connection relies on trusting the OS. Michal: True,
however in this case the OS cannot access the keys. Marcel: GSX leaks RSA keys
through timing attacks.

Christof: Static scenarios or high mobility scenarios?
Michal: Static is easier, but mobile scenarios will have to be considered.
Christof: As long as you don't have too much mobility on your route to your
node, I think this RTC measure could help on how to maintain PIT states and how
to keep track of timeouts.


Note Taker (after morning break): Philipp Moll

ICMP/ICN Panel Discussion

Dave introduces the need for non-Application Messages for ICN
Discussion of design-issues and ideas

1) We need easy ways to bootstrap ICN nodes.
2) Need for neighbor initialization.
3) Ways to report local errors, without propagating the local error all over
the world.

Q: Do we need a different propagation model for managing control state?
Q: How to securely bootstrap nodes and adjacencies without global keying?
Q: What are interactions with L2 protocols?

Thomas C. Schmidt talks about the need for ICMP for NDN (Slides online)
The request-response principle of CCN/NDN is valuable from the security
perspective. Nodes are not directly addressable,... Could a push-message be
useful when bootstrapping a node? It is considered as harmful to introduce Push
packets. It breaks the paradigm. Persistent Interests/subscriptions introduces
a persistent data path and can cause broadcast disasters. Interest notification
(data is sent in interest). Also breaks the paradigm. The interest follows
interest approach does not break the paradigm. We need a clean design for the
control state transfer.

Christian Tschudin talks about fraudulent names. Some names pretend to be
ordinary names, but they need different treatment. (e.g. local only for one
hop) It is important to add namespaces, in order to declare how a request
should be treated. Furthermore, we need the possibility to ask the neighbour
what he can do. Before we can start talking with the neighbour using the
request-reply principle, we have to associate with the neighbour.

Dave: With this scheme, a node has to know a lot of the packet in order to be
able to forward it. Thomas: The network behaviour has to be transparent. Ken:
You can not prevent people from having conventions. Dave: Scoping should not be
part of the name. If something is local, it should be declared as attribute of
the interest, but not in the name. Two possible approaches, Hop-Count
restrictions and administrative scoping (do not propagate behind this boundary)
Christian: There should not be too much information in one name. Christian:
Nodes have to know if there is a classical Interest-Data connection, or if
there is something different, like an interest invoking a long running
function. Dirk: We have to avoid the "second-system" syndrome.

Thomas: Control "things" should be clearly visible on all nodes. The meaning of
control messages should be clear for all nodes. It is difficult to establish
naming conventions. Dave: What if we need a control protocol that goes more
than one hop?

There are existing control protocols to securely join networks, which already
use messages that cross multiple hops. All intermediate nodes need to
understand the message and do computations based on this messages.

Dirk: It could be a problem in the long run, if all nodes need to know how to
interpret all messages.

14h - 15h30
Note taker after lunch: Bastiaan Wissingh

ICN Congestion Control - How to handle unknown link capacity? (Bengt Ahlgren)
-- 20 min
                Dave: do you model the fact that instead of interest drop, you
                get a nack back. Is that in there? Bengt: Yes, it is in there

                Dirk: second item slide 10, how does that compare to data
                center tcp? Bengt: queuing algorithms wont work with overlay,

                Lotfi: Not all work is based on knowing link capacity, such as
                recent work by Klaus Schneider at University of Arizona “PCON”
                presented at last year’s ACM ICN and being deployed on the NDN

                Christian: tcp fairness in multihop wireless networks research
                done by PhD student. Need to take into account two hop
                neighborhood information. Bengt: Christian: we created island
                view, filter at ingress to find estimator to propagate

                Dave: firstly, it seems a bit concerning that the control
                estimation seems a bit tcp like. Secondly: scheduling on both
                sides of the link seems independent in what you are presenting,
                however this is not the case. Bengt: We are doing work on that,
                but it is not shown here.

                Bengt: Is this a way to go for an estimator on the available
                bandwidth? Dave: Have you read Keith Winstein's PhD? Shows that
                wireless bandwidth prediction can be reasonably accurate over
                timescales up to 300ms
               Mayutan: what is your thought on fairness?
                Bengt: I had hoped it would be more fair between clients, but
                current simulations do not yet show that. It also depends on
                the clients used.

                Lotfi: you estimate link capacity, do you also need to estimate
                the number of flows? Bengt: not (yet)

"Interconnection of testbeds to enable better testing" (GEANT_GTS+NDN testbed)
(Jacopo De Benedetto, Mayutan Arumaithurai) -- 20 min
                No questions

RIOT & CCN-Lite Update (Cenk) -- 15 min
                Thomas: what do you mean by arm? Do you mean as OS?
                Christopher: Works on arm based Unix architectures
               Mayutan: ccn lite could do ndn or ccnx, is that
                                still possible?
        Christopher: yes
        Mayutan: so what is the difference between ccn-lite with ndn and
        ndn-riot? Dave: different people wrote the code, so hence there are
        differences Christopher: in principle ccn-lite is not bound to one

        Mayutan: Standard compliant? Is ccnx complieant to ICNRG document
        Christopher: yes

        Thomas: if in constrained IoT if we don't want dynamic memory
        allocation? Then we can not really have fixed name constraints right?
        Dirk: you mean maximum length of names? Thomas: Yes Dirk: who has the
        authority? Thomas: we have been discussing this for quite some time. I
        mean you can not really stream lots of video data on constrained IoT
        devices. Christopher: what if you try to put the interest in 1 MTU?
        Dave: maybe we can be more flexible for IoT? So for certain
        applications decide on a maximum length of the names. Ken: How about
        the filesystems supported in RIOT, do they have a maximum length of the
        filepath for example? Cenk: Yes they do, but differs per filesystem.
        Multiple systems are supported. Christopher: Strongly interested to
        have as dynamic names as possible, for example for NFN. Christian: The
        word NET has not been mentioned yet... Name translations services is an
        interesting topic to me, e.g. translate between CCNx and NDN names. If
        people are interested to work on that, let me know. Dirk: of course
        implementation constraints, but IoT applications can leverage on
        different implementations (constraints). So it seems really an
        implementation constraint.

        Bengt: it might become a problem in a multi-vendor installation. If
        vendors decide themselves on the maximum length of the name.

802.15.4 ICN Adaptation Layer (Cenk) -- 15 min
                Dirk: translation from TLV bi-jective?
                Cenk: yes
             Dave: do you attempt to compress the name at all?
                Cenk: we talk a bit about it in the draft.

                Christian: can you add your experiences? How much you gained?
                Cenk: we have numbers in the draft.
                Dirk: two interesting dimensions: packet size, and coding
                decoding effort.

Summary and discussion of T2TRG and RIOT meetings (from an ICN perspective) (if
time permits)

                Dirk gives a summary of the meetings of past week.
               ICN paradigm is to access named data.

                T2T on the other hand is to design IoT solution in the
                architecture of the Interent. Involving translation and
                gateways. One of the current workitems is symantic

                Another topic was Blockchain and how to use that for IoT.

                Interesting presentation by Laura P?, how do you manage these
                different types of networks their spectrum usage while these
                different types of networks know nothing about each other.
               T2T also (as us) talks a lot about Edge
                                Computing. T2T also seems to have problems with
                                the way in which (current) networks do Edge
                                Computing, quite some discussions about that.

Note taker after break: Ken Calvert

Time Perception in NDN - Dave Oran (work with Karim Habak & Mark Stapp)
Components of interest satisfaction time: network time + application response
<- can be much larger; in fact these are on different scales. also loss
recovery time.  Thesis: there are drawbacks to having a single interest
satisfaction timeout (=interest lifetime). Why don't we have this problem in IP
world? Because they are decoupled in TCP. Goal: minimize interest satisfaction
time. [see slides] Issue with thunks [_____]: what if the thunk is cached? Now
someone later asks for the result again... Dave: ref name needs to be
constructed so it's unique to that request.  (Caching still helps with error
recovery!) Q [____]: Were acks end-to-end, or did they change intermediate
state? A: Ack goes back but doesn't wipe out PIT.  Does annotate that it went
by (resets timer so it switches to application timeout).

(No further discussion.)

Next meeting: Singapore.  Planning for a meeting sometime middle of the week
during IETF.  Send email to chairs with things you would like to present.