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