Subject: [icnrg] Draft Minutes of Berlin Interim: resend as inline text

From: "David Oran" <[email-masked]>
Date: Fri, 06 Oct 2017 14:04:01 -0400

Corrections/additions to Dave Oran. These will be published by next 
Monday, so please take some time to look at them before the end of the 
weekend.

Thanks to everyone who attended and participated. It was a very 
productive day!

update: windows machines seem to barf at the text file in the 
attachment, so I’m pasting the full minutes below:

————————

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

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 units;
		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 info.
     
	•	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 
generation/production?

-----------------------------------------------

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.

-----------------------------------------------
		BREAK
-----------------------------------------------

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.

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

ICN Congestion Control - How to handle unknown link capacity? (Bengt 
Ahlgren) -- 20 min
		Q&A
		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, right?

		?1: Not all work is based on knowing link capacity. Recent work on 
unknown link capacity. Poster at this ACM ICN. Paper on NDN website.

		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.

		?1: estimate link capacity, do you also estimate flows?
		Bengt: not (yet)

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

RIOT & CCN-Lite Update (Cenk) -- 15 min
		Q&A
		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 
implementation

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

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