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
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;
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" --
• 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
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
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
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
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
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?
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
Summary and discussion of T2TRG and RIOT meetings (from an ICN perspective) (if
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.