September 27, 2019 Macau University
Note taker: Onur Ascigil
Update on touchndn and the recent workshop.
Dirk: How did you do the integration of Touchdesigner with NDN?
Jeff: Touchdesigner is essentially a game engine. There is asynch communication and AWS integration. Overall, it wasn’t hard. Video streaming over NDN did not require much integration effort. Only involved design decisions such as which strategy to use, etc.
Dirk: How do you sell NDN to the game engine designers?
Jeff: No IP configuration necessary. Also, being able to publish streams that are selectable (request particular tiles which have names and other annotated information) is a big plus. Receiver driven design is convenient. There is no equivalent functionality in IP as far as we know. IP configuration is difficult and requires network engineering with setting up ports.
Jeff: Another big advantage (and main selling point) for NDN is the support for redundant producers. This is painful to support in IP. However, currently the NDN strategies confound this a bit in a LAN setting.
Dirk: Who has followed the lowpan work here?
Dirk: We have to make sure that this gets exposed to people who followed this work. Have you talked to Marc Mosco ?
Cenk: We reached out to people on the icnrg email list. There are two on-going threads in the email without much response.
Dirk: How much did we move forward on this topic since the last meeting?
Cenk: From last time, we had only naming issue discussion. We attempted to solve the naming issue with extensibility, which supports multiple compression schemes.
Boerje: As an action item to the chairs – Send a reminder to the mailing list for people to respond and give feedback.
Dirk: Really interesting topic and comparison to other QoS work is nice. Can you summarise why the IoT work needs something special? Isn’t flowcast sufficient for the IoT scenario?
Cenk: Flowcast proposes to put flow information in the packet to manage resources, which inflates the packets. We use a simple longest-prefix match approach, but this is not yet in the draft.
Dirk: It would be nice to specify the exact behaviour and make it applicable to both the regular ICN and the IoT worlds. There are essentially same resources – the solution should be conceptually the same:
Cenk: In IoT, the main constraint is the memory resources. They saturate much faster than the bandwidth resources.
Thomas Schmidt: There is a major difference in IoT than in regular networks. In regular networks, you use caches to replicate content for the consumption of many consumers. In the IoT, the use of caches is different. Content/Data is not generaly consumed by many. Caching is used mostly for retransmissions. This makes resource (cache) management different in the case of IoT than the regular ICN networks.
Dirk: We should still try for a broader network support. We may need in IoT finer grained control of resources and orchestrate the behaviour better. A framework that is applicable to different network environments would be great.
Cenk: Currently, the aggregation of flows is not possible. Dave’s flowcast approach can do aggregation. We are currently looking into this. Our approach is optimised to use less bytes in the packets.
Dirk: A workshop activity in the QoS space would be nice. Maybe we can have a hackaton on this topic. We should think about that.
Introduction: Opportunities for ICN/LoRa – Dirk Kutscher
Onur: Can you deploy computing resources in this network as in an edge computing sceanrio? *Dirk : This is certainly possible. There may be opportunities to do filtering operations on gateways or offload computing from end nodes.
Thomas: … (?) Vertical slices (from 5G networks) deployment can also be an option. This can be a poster child of SG.
Dirk: There are of course other issues that I didn’t get into such as security, bootstrapping (how does a node join the system), and so on. Also it would be interesting to setup an ISP-like network with lora and the challanges there should be interesting.
Dirk: How do you use NDN in your system? Are you using NDN from constrained device to backend? Where is the use of NDN in the system?
Xiayou: NDN-lite is used by the smart water collectors – i.e., Data concentration units (MCU). For instance, one building can have many collectors (MCUs). They collect data using the Lora network within a range of 1 km or so. An area (of 1km range) can have many (100-200) collectors. If one MCU fails, we can still collect the data from others.
Dirk: We don’t know how NDN is using the MAC layer? Lora has different message types. How NDN is making use of that? Is this a proprietary extension?
Xiayou: We used NDN-lite on low power devices (smart meters on batteries).
Namseok Ko: Is there a prototype of your deployment?
Xiayou: We are in the process of a techincal trial using NDN. We have replaced the 2g/3g radios of MCUs and used LORA communication (on unlicensed spectrum) instead.
Namseok Ko: You mentioned 100 MCU deployment in your talk. How are they used? Do you synchronise every data with all the MCUs?
Xiayou: We built a small network with 100 MCUs. The collection system can withstand failures, e.g., an MCU failing. Xiayou describes a demo on the slides.
Peter: About the adaptation layer for Lora and NDN-lite: is this your own contribution? Did you design a Face adaptor? Is the code that connects NDN-lite and LORA in a public repository such as github?
Xiayou: We designed an adaptor for the connection. It is not yet available on github. We will share the code eventually.
Peter: Did you evaluate whether LoRa,/LoRaWAN is sufficient for your project? Why do you need NDN in your meter data collection instead of standard solution?
Xiayou: We have other teams that are using LORA solution directly. NDN helps us with distributed storage. Recovering data becomes easy. We separate coded data into blocks so we can recover data even with 50% loss.
Boerje: Is ease of application development with NDN names important for you? Does naming make it easy for applications (collecting meter data) to use the data?
Xiayou: Discussion taken offline
Namseok Ko: From sensor nodes, ie. MIU (smart meters) that are operated on batteries? When data is generated from node. Do they have signatures? Signatures would be an overhead for battery-operated meters.
Xiayou: no answer really.
Borje: How often do you collect data from smart meters?
Xiayou: The devices wake up every four hours or so. Not very frequent.
irk: Interesting to composition very idea is to write the details of the NDN face adaptor. We would like to learn about the technical details. For instance, if you see any problems (power consumption, etc.), how do you send the data? Do you send an Interest?
Borje: more technical details can be discussed in Singapor Hackathon.
Xiayou : there will be somebody from our group there to discuss the details.
Dirk: You can also join the icnrg email list.
Michal: The distinction between push vs. pull seems artificial in that push is essentially a pull with given credit. A pull has a credit of one. Aren’t they conceptually the same thing?
Christian: AOP is a pushified version of event streaming; a reliable pub-sub and producer-centric. The design decision on push vs. pull is also about how often the subscription happens. Push has less subscription overhead as opposed to repeated pulls. AOP can also support nodes going offline and coming back up with persistent state.
Michal: This proposal seems to be equivalent to pushing application-level semantics to TCP. Pushing the application layer to TCP sequence number namepace.
Christian: In AOP, there is kind of a session layer, which we don’t have in TCP.
Dirk: There is no congestion control.
Christian: Flow-control is hop-by-hop. There is competition among flows within a node which brings the question of scheduling. We can’t do e2e fairness. Fairness of information propagation has to be rethought in NDN.
Dirk: How do you link this to psync? psync has an append only log. set reconsiliation.
Christian: pysync has no causality. You have to count the items individually.
Michal: Can you have holes in the transmissions (as in the tcp receive window) where you miss some packets in the middle? Can we use selective ack or nack mechanism for the re-transmission of such packets?
Christian: These are implementation details and certainly doable.
Boerje: Can AOP work on resource-constrained devices?
Christian: The “wish list” and “have list” can grow infinitely, which means bad news for resource consumption. However, similar to tcp, we can have a sliding window so we can reduce the sizes of these lists. This can be solved at the application-level.
Dirk: looking forward to see the throughput graphs.