Dirk Kutscher

LoRaWAN is a popular low-power long-range communication system for IoT that is suitable for single-site deployments as well as for larger networks. It consists of LoRa, a PHY layer that allows for radio communication between 2 and 14 km, and higher-layer protocols mainly to upload IoT data to a serverbased infrastructure. These characteristics make LoRaWAN a promising option for many urban and rural IoT scenarios.

The LoRaWAN network design incurs, however, four notable shortcomings:

1. LoRaWAN is heavily optimized towards retrieving data from constrained Nodes. Sending data to Nodes is expensive and involves significant latencies. Many networks such as the popular community The Things Network (TTN) thus deprecate sending data to Nodes above a very low message rate, making LoRaWAN unsuitable for most control scenarios.
2. LoRaWAN has not been designed with the objective to provide a platform for Internet protocols. It is possible to use IP and adaptation layers on top of LoRaWAN, albeit very inefficiently.
3. The whole LoRaWAN system is a vertically integrated stack that leads to inflexible system designs and inefficiencies. For example, all communication is channeled through LoRaWAN Gateways as well as Application- and Network Servers that interconnect with applications.
4. The centralization and lock-in into vertical protocol stacks challenge data sharing (between users) and the creation of distributed applications (across LoRa island and the Internet).

A new LoraWAN architecture based on DSME and ICN

In our IFIP Networking 2022 paper "Long-Range ICN for the IoT: Exploring a LoRa System Design", Peter Kietzmann, José Alamos, Thomas C. Schmidt, Matthias Wählisch, and myself aim for a better integration of the LoRa-based Internet of Things into the remaining Internet. We base our system design on the following four requirements:

1. enabling LoRa networks and Nodes in these networks to communicate directly with hosts on the Internet;
2. empowering LoRa Gateways to act as routers, without the need to employ Network Servers and to tunnel all traffic to or from them;
3. enabling secure data sharing and wireless Node control; and
4. maintaining the important power conservation and robustness properties of current LoRaWAN systems.

To achieve these goals without abandoning the benefits of the LoRA PHY (i.e., a robust, energy-efficient long-range communication channel) we developed both a complete redesign of the MAC layer and a data-oriented network layer on top. Our work leverages two key building blocks.

1. the Deterministic and Synchronous Multi-Channel Extension (DSME) extension to IEEE 802.15.4e, a flexible MAC layer that consists of contention-access and contention-free periods, and,
2. the Information-Centric Networking (ICN) protocol NDN, which provides secure access to named data in networks.

LoRa and ICN

Prior work showed that ICN provides clear benefits over traditional IP and CoAP or MQTT stacks in the IoT. Our research showed that ICN is also well-suited for LoRa networks because its hop-wise data replication increases robustness and flexibility while reducing retransmission load. This enhances adaptivity and decreases communication overhead, whereas link capacity is scarce with LoRa. Named and authenticated data access enables location-independence since applications can access named data directly, without resorting to lower-layer addresses. Furthermore, built-in caches in ICN facilitate more efficient LoRa networks. Requests that are satisfied by an in-network cache

1. reduce link utilization, to improve on air time and wireless interference;
2. facilitate Node sleep; and
3. reduce long round trips introduced by slow transmissions.

Results

In our paper, we describe

1. the design of ICN over LoRa, including a suitable DSME configuration and options for mapping ICN messages to DSME;
2. a complete simulation environment in OMNeT++ that combines ccnSim as an ICN stack, openDSME as a MAC layer, and FLoRa to simulate LoRa-type devices—and a demonstration of our adaptation layers in that system.
3. Preferred mappings and additional Node requirements for implementing relevant ICN interaction patterns, based on our simulation results.

Code and documentation is available at https://github.com/inetrg/IFIP-Networking-LoRa-ICN-2022, and the whole system is currently being implemented for the RIOT Operating System.

References

• Peter Kietzmann, Dirk Kutscher, Thomas C. Schmidt, Matthias Wählisch;
  Long-Range IoT: Is LoRaWAN an option for ICN?; Proceedings of the 7th ACM Conference on Information-Centric Networking; September 2020; Pages 152–154; DOI10.1145/3405656.3420228
• Peter Kietzmann, José Alamos, Dirk Kutscher, Thomas C. Schmidt, Matthias Wählisch
  Long-Range ICN for the IoT: Exploring a LoRa System Design; IFIP Networking 2022; Catania, Italy; June 2022

I was on The Hedge Podcast with Russ White and Alvaro Retana to discuss Information-Centric Networking and the future of the Internet.

Ubiquitous virtual reality environments such as Metaverse have been described as the future mobile Internet, alluding to their expected profound impact on the way how information is retrieved, processed, rendered, and consumed. While detailed designs are still emerging, early visions such Keeichi Matsuda’s Hyper-Reality project have already outlined usage models and expectations on connectivity and data availability to enable rich interactions with the physical world and blending it with dynamically computed artefacts.

Metaverse systems will challenge traditional client-server-inspired web models, centralized security trust anchors and server-style distributed computing. The new network will be based on dynamic interactions between humans, the phyiscal world, and computing processes in an edge-to-cloud continuum. This talk will outline the associated challenges, review recent work in distributed computing and suggest some approaches for evolving networking and computing to enable Metaverse – not as a dystopian vision but as an opportunity for societies and their citizens.

Download presentation

The Dataflow paradigm is a popular distributed computing abstraction that is leveraged by several popular data processing frameworks such as Apache Flink and Google Dataflow. Fundamentally, Dataflow is based on the concept of asynchronous messaging between computing nodes, where data controls program execution, i.e., computations are triggered by incoming data and associated conditions. This typically leads to very modular system architectures that enable re-use, re-composition, and parallel execution naturally. Most of the popular distributed processing frameworks today are implemented as overlays, i.e., they allow for instantiating computations and for inter-connecting them, for example by creating and maintaining communication channels between nodes such as system processes and microservices.

Connections and Overlays

The connection-based approach incurs several architectural problems and inefficiencies, for example: application logic is concerned with receiving and producing data as a result of computation processes but connections imply transport endpoint addresses that are typically not congruent. This typically implies a mapping or orchestration system. One key goal for Dataflow systems is to enable parallel execution, i.e., one computation is run in parallel, which also affects the communication relationships with upstream producers and downstream consumers. For example, when parallelizing a computation step, it typically implies that each instance is consuming a partition of the inputs instead of all the inputs. An indirection- and connection-based approach makes it harder to configure (and especially to dynamically re-configure) such dataflow graphs.

In some variants of Dataflow, for example stream processing, it can be attractive if one computation output can be consumed by multiple downstream functions. Connection-based overlays typically require duplicating the data for each such connection, incurring significant overheads. In large-scale scenarios, the computation functions may be distributed to multiple hosts that are inter-connected in a network. Orchestrators may have visibility into compute resource availability but typically have to treat the TCP/IP network as a blackbox. As a result, the actual data flow is locked into a set of overlay connections that do not necessarily follow optimal paths, i.e., the communication flows are incongruent with the logical data flows.

IceFlow: Information-Centric Dataflow

In our ACM ICN 2021 paper Vision: Information-Centric Dataflow – Re-Imagining Reactive Distributed Computing, we present IceFlow – an Information-Centric Dataflow system approach that supports traditional Dataflow with Information-Centric principles and that can be used as a drop-in replacement for existing Dataflow-based frameworks.

In addition to the paper, we also show a live of a joint optimization of computing and networking resources in IceFlow: Decentralized ICN-based dataflow system implementation.

IceFlow’s objectives are:

1. reducing complexity in Dataflow systems by removing connection-based overlays and corresponding orchestration requirements;
2. enabling efficient communication by reducing data duplication; and
3. enabling additional improvements through more direct communication and caching in the network.

IceFlow is employing access to authenticated data in the network as per CCNx/NDN-based ICN for the communication between computation functions and provides additional features such as flowcontrol, partitions for data streaming, and a window concept for synchronizing computations in streaming pipelines. The contributions of this paper are:

1. an ICN naming scheme for Dataflow;
2. a concept for receiver-driven flow control in IceFlow-based Dataflow systems and for dealing with parallel processing in IceFlowbased Dataflow systems; and
3. a prototype implementation.

Links

• ACM ICN 2021
• Vision: Information-Centric Dataflow – Re-Imagining Reactive Distributed Computing
• Decentralized ICN-based dataflow system implementation

In der neuen Folge unseres Podcasts Neulich im Netz widmen wir uns eines etwas delikateren Themas: Zensur im Internet

Insbesondere geht es um die "Great Firewall of China" (GFW), die wir in Bezug auf ihre technische Umsetzung und Probleme analysiert haben.

Anhand von Publikationen und eigenen Erfahrungen analyisieren wir, wie die GFW grob funtioniert, kontinuiierlich weiterentwickelt wird, und wie effektiv unterschiedliche Werkzeuge wie VPNs, shadowsocks usw. sind.

Diese und weitere Aspekte von Zensur im Internet in der dritten Episode von Neulich im Netz.

In der neuen Folge unseres Podcasts Neulich im Netz geht um Namen im Internet, d.h., um das Domain Name System (DNS). Wir sprechen über grundlegende DNS-Funktionen, die Bedeutung, die das DNS für das Internet und das Web hat und über Anwendungen wie Tracking und Traffic Steering, die man vielleicht nicht unbedingt mit Namensauflösung in Verbindung bringt.

Wir diskutieren, inwieweit das technische Design des DNS und seine heutige Verwendung zu Sicherheitsproblemen führt und beurteilen einige vorgeschlagene Verbesserungen. Ist das DNS in der heutigen Form noch zu retten? Wie stehen die Chancen dafür? Diese und andere Frage in der zweiten Episode von Neulich im Netz.

Low-power, long-range radio systems such as LoRaWAN represent one of the few remaining networked system domains that still feature a complete vertical stack with special link- and network layer designs independent of IP. Similar to local IoT systems for low-power networks (LoWPANs), the main service of these systems is to make data available at minimal energy consumption, but over longer distances. LoRaWAN (the system that comprises the LoRa PHY and MAC) supports bi-directional communication, if the IoT device has the energy budget. Application developers interface with the system using a centralized server that terminates the LoRaWAN protocol and makes data available on the Internet.

While LoRaWAN applications are typically providing access to named data, the existing LoRaWAN stack does not support this way of communicating. LoRaWAN is device-centric and is generally designed as a device-to-server messaging system – with centralized servers that serve as rendezvous point for accessing sensor data. The current design imposes rigid constraints and does not facilitate accessing named data natively, which results in many point solutions and dependencies on central server instances.

In our demo paper & presentation at ACM ICN-2020, we are therefore describing how Information-Centric Networking could provide a more natural communication style for LoRa applications and how ICN could help to conceive LoRa networks in a more distributed fashion compared to todays mainstream LoRaWAN deployments. For LoWPANs (e.g., 802.15.4 networks), ICN has already demonstrated to be an attractive and viable alternative to legacy integrated special purpose stacks – we believe that
LoRa communication provides similar opportunities.

Watch my Peter Kietzmann's talk about it here:

Edge- and, more generally, in-network computing is receiving a lot attention in research and industry fora. What are the interesting research questions from a networking perspective? In-network computing can be conceived in many different ways - from active networking, data plane programmability, running virtualized functions, service chaining, to distributed computing. Modern distributed computing frameworks and domain-specific languages provide a convenient and robust way to structure large distributed applications and deploy them on either data center or edge computing environments. The current systems suffer however from the need for a complex underlay of services to allow them to run effectively on existing Internet protocols. These services include centralized schedulers, DNS-based name translation, stateful load balancers, and heavy-weight transport protocols.

Over the past years, we have been working on alternative approaches, trying to find ways for integrating networking and computing in new ways, so that distributed computing can leverage networking capabilities directly and optimize usage of networking and computing resources in a holistic fashion.

From Application-Layer Overlays to In-Network Computing

Domain-specific distributed computing languages like LASP have gained popularity for their ability to simply express complex distributed applications like replicated key-value stores and consensus algorithms. Associated with these languages are execution frameworks like Sapphire and Ray that deal with implementation and deployment issues such as execution scheduling, layering on the network protocol stack, and auto-scaling to match changing workloads. These systems, while elegant and generally exhibiting high performance, are hampered by the daunting complexity hidden in the underlay of services that allow them to run effectively on existing Internet protocols. These services include centralized schedulers, DNS-based name translation, stateful load balancers, and heavy-weight transport protocols.

We claim that, especially for compute functions in the network, it is beneficial to design distributed computing systems in a way that allows for a joint optimization of computing and networking resources by aiming for a tighter integration of computing and networking. For example, leveraging knowledge about data location, available network paths and dynamic network performance can improve system performance and resilience significantly, especially in the presence of dynamic, unpredictable workload changes.

The above goals, we believe, can be met through an alternative approach to network and transport protocols: adopting Information-Centric Networking as the paradigm. ICN, conceived as a networking architecture based on the principle of accessing named data, and specific systems such as NDN and CCNx have accommodated distributed computation through the addition of support for remote function invocation, for example in Named Function Networking, NFN and RICE, Remote Method Invocation in ICN and distributed data set synchronization schemes such as PSync.

Introducing Compute First Networking (CFN)

We propose CFN, a distributed computing environment that provides a general-purpose programming platform with support for both stateless functions and stateful actors. CFN can lay out compute graphs over the available computing platforms in a network to perform flexible load management and performance optimizations, taking into account function/actor location and data location, as well as platform load and network performance.

We have published a paper about CFN at the ACM ICN-2019 Conference that is being presented in Macau today by Michał Król. The paper makes the following contributions:

1. CFN marries a state-of-the art distributed computing framework to an ICN underlay through RICE, Remote Method Invocation in ICN. This allows the framework to exploit important properties of ICN such as name-based routing and immutable objects with strong security properties.
2. We adopted the rigorous computation graph approach to representing distributed computations, which allows all inputs, state, and outputs (including intermediate results) to be directly visible as named objects. This enables flexible and fine-grained scheduling of computations, caching of results, and tracking state evolution of the computation for logging and debugging.
3. CFN maintains the computation graph using Conflict-free Replicated Data Types (CRDTs) and realizes them as named ICN objects. This enables implementation of an efficient and failure-resilient fully- distributed scheduler.
4. Through evaluations using ndnSIM simulations, we demonstrate that CFN is applicable to range of different distributed computing scenarios and network topologies.

Resources and Links

• My keynote at IEEE CCNC-2019 on Compute-First Networking (CFN): New Perspectives on Integrating Computing and Networking
• Internet Draft draft-kutscher-coinrg-dir-00 with Jörg Ott and Teemu Kaerkkaeinen on Directions for Computing in the Network (COIN) and the corresponding presentation.
• The CFN paper at ACM ICN-2019: Compute First Networking: Distributed Computing meets ICN. The author team: Michał Król, Spyridon Mastorakis, David Oran, Dirk Kutscher
• CFN builds on our earlier work on RICE, Remote Method Invocation in ICN, authored by: Michał Król, Karim Habak, Karim Habak, Dirk Kutscher, Ioannis Psaras
• 1st ACM CoNEXT Workshop on Emerging in-Network Computing Paradigms (ENCP)
• IRTF Computing in the Network Proposed Research Group (COIRG)

We (ICNRG) published RFC 7927 on Information-Centric Networking (ICN) Research Challenges.

This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.

Information-Centric Networking (ICN) is an approach to evolve the Internet infrastructure to directly support accessing Named Data Objects (NDOs) as a first-order network service. Data objects become independent of location, application, storage, and means of transportation, allowing for inexpensive and ubiquitous in-network caching and replication. The expected benefits are improved efficiency and security, better scalability with respect to information/bandwidth demand, and better robustness in challenging communication scenarios.

ICN concepts can be deployed by retooling the protocol stack: name-based data access can be implemented on top of the existing IP infrastructure, e.g., by allowing for named data structures,
ubiquitous caching, and corresponding transport services, or it can be seen as a packet-level internetworking technology that would cause fundamental changes to Internet routing and forwarding. In summary, ICN can evolve the Internet architecture towards a network model based on named data with different properties and different services.

This document presents the ICN research challenges that need to be addressed in order to achieve these goals. These research challenges are seen from a technical perspective, although business relationships between Internet players will also influence developments in this area. We leave business challenges for a separate document, however. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research work.

Continue reading...

Mobile network designs have to meet several, at first sight contradicting, requirements: maximize resource utilization, provide optimal performannce (user-perceived quality of experience), enable operator-defined "fair usage" policies, maintain user privacy and minimize management complexity.

For 5G networks, virtual network slicing is often mentioned as one the desirable properties, i.e., the ability to run virtual networks for different application classes (service slicing) or different customer groups (MVNOs etc.) over the same physical infrastructure. Virtualizing networks over a larger set of shared resources (radio networks, backhaul, data centers) requires effective and efficient means for capacity sharing.

Capacity sharing can be done in different ways: traditionally, telco network capacity sharing has been inspired by telephony network architectures with an emphasis on control plane-based monitoring, resource allocation and configuration. Such approaches often involve traffic management systems that monitor performance, load etc. of network elements, analyze traffic properties (for example, DPI-based traffic inspection) and configure network elements such as base station and gateways to implement certain rate limits based on operator policies.

Three trends make this difficult in present and future networks:

1. with virtualization, slicing etc., the effort of analyzing every single tenant's flows can be increasingly prohibitive;
2. encryption-by-default with HTTP2 and other protocols that employ connection-based encryption renders DPI-based approaches costly (at best -- if not impossible); and
3. Internet protocols and applications such TCP (transport layer) and DASH-based video streaming over HTTP (application layer) are themselves adaptive to congestion, delay and overall observed performance. New protocols with specific requirements are invented all the time (think IoT, Virtual Reality). Interfering with their control loops through network traffic management may yield bad performance, suboptimal user preference and higher cost overall.

The idea of enabling an effective capacity sharing with a productive cooperation of operator policy decision making and dynamic application/user resource utilization has driven the work in the IETF ConEx working group. Based on earlier work by Bob Briscoe on Re-Feedback, the ConEx WG has defined concepts and (experimental) mechanisms for congestion exposure, enabling a form of capacity sharing that incentivizes senders to respond to congestion signals, while still enabling operators with hooks for auditing and enforcing correct behavior.

RFC 7778 describes how the ConEx mechanisms can be applied to current LTE (EPS) networks, considering their specifics regarding QoS and network architecture. For example, RFC 7778 described how ConEx can

• enable or enhance flow policy-based traffic management;
• reduce the need for complex DPI by allowing for a bulk packet traffic management system that does not have to consider either the application classes flows belong to or the individual sessions; and how it can
• be used to more effectively trigger the offload of selected traffic to a non-3GPP network.

More experiments with ConEx and related capacity sharing mechanisms are needed, but the questions behind ConEx remain important for 5G (and beyond...): How to achieve an effective collaboration of networks and their users (senders and receivers) considering increased need for capacity sharing, increased demand for user privacy (connection encryption) and the permissionless innovation feature of the Internet, i.e., not expecting the network to know all possible application classes and their traffic management requirements.