Dirk Kutscher

Personal web page

Archive for the ‘Publications’ Category

The Metaverse as an Information-Centric Network

without comments

This is an introduction to our paper:

The Web Today

The Web today has a specific technical definition: it includes presentation layer technologies, protocols, agreed-upon ways of achieving certain semantics such as Representational State Transfer (REST), and security infrastructure. However, from a user perspective, it can be viewed as a universe of consistently navigable content and (occasionally) interoperable services. The user experience and architectural underpinnings have evolved in parallel and have influenced each other: for many end users, the Web and the network are synonymous. Rather than building up "Metaverse" as an application domain based on IP, we aim to explore "the Metaverse" as strongly intertwined with ICN, just as the modern concept of the Web and its technology stack are inseparable for a broad set of applications.

As a placeholder name for a range of new technologies and experiences, "the Metaverse" is even less well-defined than the Web. We adopt the commonly used concept of a shared, interoperable, and persistent XR. Some descriptions and early prototypes for social AR/VR systems suggest leveraging existing Internet and Web protocols to provide Metaverse services, without addressing the technical complexity and centralization of control required to provide the underlying cloud service infrastructure.

Metaverse as an Information-Centric Concept

Here, we do not take as given current designs and deployment models that consider the Metaverse as an overlay application with corresponding infrastructure dependencies, as this exacerbates the current gaps (and the resulting costs and technical complexity) between distributed applications and the underlying network architecture. Instead, we assume a fundamentally information/centric system in which most applications participate in granular 3D content exchange, context-aware integration with the physical world, and other Metaverse-relevant services.

"The Metaverse" is an information-centric concept that likely will become synonymous with the network itself. We argue that reciprocal design of the network and applications will open new opportunities for the deployment of Metaverse-suggestive experiences even today.

Experientially, this Metaverse is an extension of the Web into immersive XR modalities that are often aligned with physical space, as in augmented reality (AR). We conceive the Metaverse not only as a shared XR environment, but the next generation of the web, extending into 3D interaction/immersion and optionally overlaid on physical spaces. Instead of rendering data objects into a 2D page (within a tab within a window) on a device, we envision such objects being rendered into a shared 3D space, interacting among each other and with end users.

Architecturally, leveraging ICN concepts provides support for decentralized publishing, content interoperability and co-existence, based on general building blocks and not within separated application silos as today's initial prototypes. We claim that such properties are required to achieve the generally circulated visions of Metaverse systems, but are not achievable today because of the host- and connection-centric way in which the web operates and is presented to users in browsers.

ICN Capabilities

We point out four ICN capabilities critical to Metaverse concepts:

  1. scalable and robust multi-destination communication, overcoming IP multicast challenges, such as inter-domain routing, scalability, and routing communication overhead;
  2. leveraging wireless broadcast to support shared local views and low-latency interactivity without application-awareness in edge routers;
  3. privacy, selective attention, content filtering, and autonomous interactions, as well as ownership and control on the publishing side; and
  4. supporting in-network processing for objects replication and transformation.

Interactive Holographic Communication

For example, imagine interactive holographic communication consisting of participants' 3D video, spatial audio, and shared 3D documents. In ICN, such an application can represent virtual content as secure data objects and share them efficiently in a larger group of peers, fetching only the data necessary to reconstruct a suitable representation while being aware of the constraints of user devices and access networks.

Furthermore, while experiencing 3D objects shared by the group, each participant may also interact in the same XR environment with personal services such as wayfinding, messaging, and Internet of Things (IoT) device status. Interactions between private and shared 3D objects would be simplified if these objects use similar conventions but with different security. This concept is semantically well-aligned with ICN properties, particularly for security, as it revolves around object-level data exchange rather than hosts or channels. Integration and interoperability within a shared XR environment, without centralization, is challenging if one has to negotiate not only data interactions but also the underlying service connections and security relationship using host-centric paradigms. It also exacerbates the impact of intermittent connectivity on interactivity when the global network is required for functions such as rendezvous -- that are handled locally in ICN.

Creating Shared Environments

As a second example, consider creating a shared environment -- e.g., to pre-visualize engineering models of an aircraft – from a collection of collaboratively edited 3D documents. Imagine component documents interacting in a simulation. Documents can be modularized, linked, and overlaid in a web-like manner. Today, such cross-platform interoperability and visualization without centralized hubs is impractical, and it is difficult to create secure, granular data flows required for interaction between co-existing 3D elements to "bring them to life" in a virtual world. In an ICN approach, such modules could be independently authored and published, shared between applications, becoming building blocks of a richer, interacting system of user- and machine-generated content.

We introduce some technical challenges and research direction in our paper (link below).

Further Reading

The Metaverse as an Information-Centric Network

References

Written by dkutscher

September 19th, 2023 at 4:49 am

Posted in Publications

Tagged with , ,

Distributed Computing in Information-Centric Networking

without comments

This is an introduction to our paper:

Distributed computing is the basis for all relevant applications on the Internet. Based on well-established principles, different mechanisms, implementations, and applications have been developed that form the foundation of the modern Web.

The Internet with its stateless forwarding service and end-to-endcommunication model promotes certain types of communication for distributed computing. For example, IP addresses and/or DNS names provide different means for identifying computing components. Reliable transport protocols (e.g., TCP, QUIC) promote interconnecting modules. Communication patterns such as REST and protocol implementations such as HTTP enable certain types of distributed computing interactions, and security frameworks such as TLS and the web PKI constrain the use of public-key cryptography for different security functions.

From Distributed Computing...

Distributed computing has different facets, for example, client-server computing, web services, stream processing, distributed consensus systems, and Turing-complete distributed computing platforms. There are also different perspectives on how distributed computing should be implemented on servers and network platforms, a research area that we refer to as Computing in the Network. Active Networking, one of the earliest works on computing in the network, intended to inject programmability and customization of data packets in the network itself; however, security and complexity considerations proved to be major limiting factors, preventing its wider deployment.

Dataplane programmability refers to the ability to program behavior, including application logic, on network elements and SmartNICs, thus enabling some form in-network computing. Alternatively, different types of server platforms and light-weight execution environments are enabling other forms of distributing computation in networked systems, such as architectural patterns, such as edge computing.

... To Computing in the Network

With currently available Internet technologies, we can observe a relatively succinct layering of networking and distributed computing, i.e., distributed computing is typically implemented in overlays with Content Distribution Networks (CDNs) being prominent and ubiquitous example. Recently, there has been growing interest in revisiting this relationship, for example by the IRTF Computing in the NetworkResearch Group (COINRG) – motivated by advances in network and server platforms, e.g., through the development of programmable data plane platforms and the development of different types of distributed computing frameworks, e.g., stream processing and microservice frameworks.

This is also motivated by the recent development of new distributed computing applications such as distributed machine learning (ML), and emerging new applications such as Metaverse suggest new levels of scale in terms of data volume for distributed computing and the pervasiveness of distributed computing tasks in such systems. There are two research questions that stem from these developments:

  1. How can we build distributed computing systems in the network that can leverage the on-path location of compute functions, e.g., optimally aligning stream processing topologies with networked computing platform topologies?

  2. How can the network support distributed computing in general, so that the design and operation of such systems can be simplified, but also so that different optimizations can be achieved to improve performance and robustness?

Issues in Legacy Distributed Computing

Although there are many distributed computing applications, it is also worth noting that there are many limitations and performance issues. Factors such as network latency, data skew, checkpoint overhead, back pressure, garbage collection overhead, and issues related to performance, memory management, and serialization and deserialization overhead can all influence the efficiency. Various optimization techniques can be implemented to alleviate these issues, including memory adjustment, refining the checkpointing process, and adopting efficient data structures and algorithms.

Some performance problems and complexity issues stem from the overlay nature of current systems and their way of achieving the above-mentioned mechanisms with temporary solutions based on TCP/IP and associated protocols such as DNS. For example, Network Service Mesh has been characterized as architecturally complex because of the so-called sidecar approaches and their implementation problems.

In systems that are layered on top of HTTP or TCP (or QUIC), compute nodes typically cannot assess the network performance directly – only indirectly through observed throughput and buffer under-runs. Information-centric data-flow systems, such as IceFlow, intend to provide better visibility and thus better joint optimization potential by more direct access to data-oriented communication resources. Then, some coordination tasks that are based on exchanging updates of shared application state can be elegantly mapped to named data publication in a hierarchical namespace, as the different dataset synchronization (Sync) protocols in NDN demonstrated.

Information-Centric Distributed Computing

In our paper on Distributed Computing in ICN at ACM ICN-2023, we focus on distributed computing and on how information-centricity in the network and application layer can support the development and operation of such systems. The rich set of distributed computing systems in ICN suggests that ICN provides some benefits for distributed computing that could offer advantages such as better performance, security, and productivity when building corresponding applications.

ICN with its data-oriented operation and generally more powerful forwarding layer provides an attractive platform for distributed computing. Several different distributed computing protocols and systems have been proposed for ICN, with different feature sets and different technical approaches, including Remote Method Invocation (RMI) as an interaction model as well as more comprehensive distributed computing platforms. RMI systems such as RICE leverage the fundamental named-based forwarding service in ICN systems and map requests to Interest messages and method names to content names (although the actual implementation is more intricate). Method parameters and results are also represented as content objects, which provides an elegant platform for such interactions.

ICN generally attempts to provide a more useful service to data-oriented applications but can also be leveraged to support distributed computing specifically.

Names

Accessing named data in the network as a native service can remove the need for mapping application logic identifiers such as function names to network and process identifiers (IP addresses, port numbers), thus simplifying implementation and run-time operation, as demonstrated by systems such as Named Function Networking (NFN), RICE, and IceFlow. It is worth noting that, although ICN does not generally require an explicit mapping of names to other domain identifiers, such networks require suitable forwarding state, e.g., obtained from configuration, dynamic learning, or routing.

Data-orientedness

ICN's notion of immutable data with strong name-content binding through cryptographic signatures and hashes seems to be conducive to many distributed computing scenarios, as both static data objects and dynamic computation results in those systems such as input parameters and result values can be directly sent as ICN data objects. NFN has first demonstrated this.

Securing distributed computing could be supported better in so far as ICN does not require additional dependencies on public-key or pipe securing infrastructure, as keys and certificates are simply named data objects and centralized trust anchors are not necessarily needed. Larger data collections can be aggregated and re-purposed by manifests (FLIC), enabling "small" and "big data" computing in one single framework that is congruent to the packet-level communication in a network. IceFlow uses such an aggregation approach to share identical stream processing results objects in multiple consumer contexts.

Data-orientedness eliminates the need for connections; even reliable communication in ICN is completely data-oriented. If higher-layer (distributed computing) transactions can be mapped to the network layer data retrieval, then server complexity can be reduced (no need to maintain several connections), and consumers get direct visibility into network performance. This can enable performance optimizations, such as linking network and computing flow control loops (one realization of joint optimization), as showed by IceFlow.

Location independence and data sharing

Embracing the principle of accessing named and authenticated data also enables location independence, i.e., corresponding data can be obtained from any place in the network, such as replication points (repos) and caches. This fundamentally enables better multi-source/path capabilities as well as data sharing, i.e., multiple data retrieval operations for one named data object by different consumers can potentially be completed by a cache, repo, or peer in the network.

Stateful Forwarding

ICN provides stateful, symmetric forwarding, which enables general performance optimizations such as in-network retransmissions, more control over multipath forwarding, and load balancing. This concept could be extended to support distributed computing specifically, for example, if load balancing is performed based on RTT observations for idempotent remote-method invocations.

More Networking, less Management

The combination of data-oriented, connection-less operation, and stateful (more powerful) forwarding in ICN shifts functionality from management and orchestration layers (back) to the network layer, which can enable complexity reduction, which can be especially pronounced in distributed computing. For example, legacy stream processing and service mesh platforms typically must manage connectivity between deployment units (pods in Kubernetes). In Apache Flink, a central orchestrator manages the connections between task managers (node agents). Systems such as IceFlow have demonstrated a more self-organized and decentralized stream-processing approach, and the presented principles are applicable to other forms of distributed computing.

In summary, we can observe that ICN's general approach of having the network providing a more natural (data retrieval) platform for applications benefits distributed computing in similar ways as it benefits other applications. One particularly promising approach is the elimination of layer barriers, which enables certain optimizations.

In addition to NFN, there are other approaches that jointly optimize the utilization of network and computing resources to provide network service mesh-like platforms, such as edge intelligence using federated learning, advanced CDNs where nodes can dynamically adapt to user demands according to content popularity, such as iCDN and OpenCDN, and general computing systems, such as Compute-First Networking, IceFlow, and ICedge.

Our paper on Distributed Computing in ICN at ACM ICN-2023 provides a comprehensive analysis and understanding of distributed computing systems in ICN, based on a survey of more than 50 papers. Naturally, these different efforts cannot be directly compared due to their difference in nature. We categorized different ICN distributed computing systems, and individual approaches and highlighted their specific properties.

The scope of this study is technologies for ICN-enabled distributed computing. Specifically, we divide the different approaches into four categories, as shown in the figure above: enablers, protocols, orchestration, and applications. The contributions of this study are as follows:

  1. A discussion of the benefits and challenges of distributed computing in ICN.
  2. A categorization of different proposed distributed computing systems in ICN.
  3. A discussion of lessons learned from these systems.
  4. A discussion of existing challenges and promising directions for future work.

Recent Research on Distributed Computing in ICN

I am providing some pointers to my previous research on distributed computing in ICN below.

The paper that has led to this article:

Current work in the Computing in the Network Research Group of the IRTF:

  • Dirk Kutscher, Teemu Kärkkäinen, Jörg Ott; Directions for Computing in the Network; Internet Draft draft-irtf-coinrg-dir-00, Work in Progress; August 2023

Reflexive Forwarding and Remote Method Invocation

Providing a unified remote computation capability in ICN presents some unique challenges, among which are timer management, client authorization, and binding to state held by servers, while maintaining the advantages of ICN protocol designs like CCN and NDN. In the RICE work,we developed a unified approach to remote function invocation in ICN that exploits the attractive ICN properties of name-based routing, receiver-driven flow and congestion control, flow balance, and object-oriented security while presenting a natural programming model to the application developer. The RICE protocol is leveraging an ICN extension called Reflexive Forwarding that provides ICN-idiomatic method parameter transmission.

Distributed Computing Frameworks

Leveraging RICE as a mechanism, we have developed Compute-First Networking (CFN) in ICN, a Turing-complete distributed computing platform. IceFlow is a proposal for Dataflow in ICN in a decentralized manner.

Applications

Based on Reflexive Forwarding, we have developed a concept for RESTful ICN that leverages CCNx key exchange for setting up security contexts and keys that could then be used for secure, data-oriented REST-like communication.

Delay-Tolerant LoRa leveraged Reflexive Forwarding to enable constrained LoRa nodes to "phone home" when they want to transmit data, thus enabling new ways (without central network and application servers) for connecting LoRa networks to the Internet.

Written by dkutscher

September 19th, 2023 at 3:47 am

ACM SIGCOMM CCR: Report of 2021 DINRG Workshop on Centralization in the Internet

without comments

ACM SIGCOMM CCR just published the report of our 2021 DINRG meeting on Centralization in the Internet.

Executive Summary

There is a consensus within the networking community that the Internet consolidation and centralization trend has progressed rapidly over recent years, as measured by the structural changes to the data delivery infrastructure, the control power over system platforms, application development and deployment, and even in the standard development efforts. This trend has brought impactful technical, societal, and economical consequences.

When the Internet was first conceived as a decentralized system 40+ years back, few people, if any, could have foreseen how it looks today. How has the Internet evolved from there to here? What have been the driving forces for the observed consolidation? From a retrospective view, was there anything that might have been done differently to influence the course the Internet has taken? And most importantly, what should and can be done now to mitigate the trend of centralization? Although there are significant interests in these topics, there has not been much structured discussion on how to answer these important questions.

The IRTF Research Group on Decentralizing the Internet (DINRG) organized a workshop on “Centralization in the Internet” on June 3, 2021, with the objective of starting an organized open discussion on the above questions. Although there seems to be an urgent need for effective countermeasures to the centralization problem, this workshop took a step back: before jumping into solution development to steer the Internet away from centralization, we wanted to discuss how the Internet has evolved and changed, and what have been the driving forces and enablers for those changes. The organizers and part of the community believe that a sound and evidence-based understanding is the key towards devising effective remedy and action plans. In particular, we would like to deepen our understanding of the relationship between the architectural properties and economic developments.

This workshop consisted of two panels, each panel started with an opening presentation, followed by panel discussions, then open-floor discussions. There was also an all-hand discussion at the end. Three hours of the workshop presentations and discussions showed that this Internet centralization problem space is highly complex and filled with intrinsic interplays between technical and economic factors.

This report aims to summarize the workshop outcome with a broad-brush picture of the problem space. We hope that this big picture view could help the research group, as well as the broader IETF community, to reach a clearer and shared high-level understanding of the problem, and from there to identify what actions are needed, which of them require technical solutions, and which of them are regulatory issues which require technical community to provide inputs to regulatory sectors to develop effective regulation policies.

You can find the report in the ACM Digital Library. We also have a pre-print version.

Written by dkutscher

July 27th, 2023 at 4:35 pm

Unlocking REST with Information-Centric Networking

without comments

Web applications today utilize the Representational State Transfer (REST) architecture pattern, depending on HTTP, TLS, and either TCP or QUIC as the protocol substrate to build upon. The resulting protocol stacks can be quite complex, and the RESTful communication is locked into channel-like connections of the respective transport protocol.

Given that most web applications are concerned with transferring named units of data (web resources, video chunks etc.), we asked ourselves: can the REST paradigm be married with the data-oriented, receiver-driven operation of Information-Centric Networking (ICN), leveraging attractive ICN benefits such as consumer anonymity, stateful and symmetric forwarding, flow-balance in-network caching, and implicit object security?

We argue that this is feasible given some of the recent advances in ICN protocol development and that the resulting suite is simpler and potentially having better performance and robustness properties. Our sketch of an ICN based protocol framework addresses secure and efficient establishment and continuation of REST communication sessions, without giving up key ICN properties, such as consumer anonymity and flow balance.

Representational State Transfer in the Web Today

The Web today is based on an extended version of the Representational State Transfer (REST) architecture pattern for client-server interaction. This simple model has been extended and applied to HTTP for web applications by supporting not only retrieval, but also creation, processing, and deletion of data. Real-world REST systems employ additional concepts and mechanisms such as security and privacy, support for application sessions, and have various optimizations to eliminate unnecessary round-trips.

REST and ICN

Since nearly all web applications today are based on the RESTful client-server communication model, the question then occurs how such interactions can be achieved in ICN, i.e., secure and confidential RESTful access to web resources, with support for efficient handling of a sequence of interactions in a session-like context.

The applicability of ICN's Interest/Data interaction to modern web applications that provide a significant amount of data in requests headers for cookies and other request parameters has been assessed by Moiseenko et al., concluding that it is not immediately clear how to use ICN effectively for web communication. We have also argued in our earlier RICE paper on Remote Method Invocation in ICN that the basic Interest/Data exchange model of CCNx/NDN-style ICN is not sufficient and that certain use cases (e.g., sending resource representations or request parameters from a client to a server) should not be implemented by overloading the Interest message.

In draft-oran-icnrg-reflexive-forwarding, we have discussed the specific problems extensively. In its default mode, ICN also lacks name privacy, which we consider essential for any real-world application of ICN to web services. However, various techniques have been developed to improve name privacy in ICN, such as the onion routing approach in ANDaNA (Anonymous Named Data Networking Application).

In our vision paper on RESTful Information-Centric Networking at [ACM ICN-2022 (https://conferences2.sigcomm.org/acm-icn/2022/), we argue that an ICN-based RESTful programming model that overcomes these limitations is feasible given some of the recent advances in ICN protocol development and provide the outline of the corresponding protocol framework.

HTTP has been extended and partially redesigned over time, and provides its own idiosyncratic conventions and mechanisms, e.g., which request-relevant information to represent in the URI vs. message headers vs. message bodies. The goal of this work is not to simply map current HTTP mechanisms to ICN, but rather to provide an ICN-idiomatic platform for RESTful applications including an Information-Centric web.

Any ICN web platform will only be useful and relevant if it provides equivalent (or better) security and privacy properties as the state-of-art, i.e., HTTP3 over QUIC and TLS 1.3, so our proposed framework provides a TLS-like security context for RESTful communication (sessions). Also, RESTful ICN should not compromise on existing ICN benefits such as consumer anonymity and consumer mobility.

Our technical design integrates CCNx Key Exchange (a TLS-1.3-like key exchang protocol for ICN) and our Reflexive Forwarding scheme for ICN, and uses that for providing symmetric key derivation and efficient RESTful communication and session resumption in an ICN-idiomatic way. Please check out our paper for details.

References

Written by dkutscher

September 16th, 2022 at 6:41 am

Posted in Publications

Tagged with , , ,

A new Delay Tolerant Networking Architecture for LoRa

without comments

Abstract

Connecting low-power long-range wireless networks, such as LoRa, to the Internet imposes significant challenges because of the vastly longer round-trip-times (RTTs) in these constrained networks. In our newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, we present an Information-Centric Networking (ICN) protocol framework that enables robust and efficient delay-tolerant communication to edge networks, including but not limited to LoRa. Our approach provides ICN-idiomatic communication between networks with vastly different RTTs for different use cases. We applied this framework to LoRa, enabling end-to-end consumer-to-LoRa-producer interaction over an ICN-Internet and asynchronous ("push") data production in the LoRa edge. Instead of using LoRaWAN, we implemented an IEEE 802.15.4e DSME MAC layer on top of the LoRa PHY layer and ICN protocol mechanisms in the RIOT operating system. For our experiments, we connected constrained LoRa nodes and gateways on IoT hardware platforms to a regular, emulated ICN network and performed a series of measurements that demonstrate robustness and efficiency improvements compared to standard ICN.

Challenging Bi-Directional LoRa Communication

LoRaWAN provides a vertically integrated network architecture for connecting LoRa networks and its constrained devices to the Internet that is designed to offload power-constrained gateways relay communication between the wireless link and network servers (often co-located with additional application server infrastructure) that manage the intricate energy-conservation regime of connected LoRa devices.

The energy conservation objectives lead to a MAC layer design that incurs dramatically higher latency and round trip times (RTTs) of several seconds, compared to what connection-oriented Internet transport protocols are typically designed to support. As a result, LoRaWAN supports message-oriented transport through gateways and dedicated network servers only, without a notion of end-to-end communication from the Internet to LoRa nodes. While it is theoretically possible to run bidirectional IP-based communication on top of LoRaWAN, the resulting systems inherit latency challenges of LoRaWAN for bi-directional communication that would impact transport layer performance and applicability.

Delay-Tolerant Information-Centric Networking

Information-Centric Networking (ICN) has demonstrated benefits for improving data availability and communication performance in constrained IoT networks.

In a newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, Peter Kietzmann, José Alamos, Thomas Schmidt, Matthias Wählisch and myself argue that ICN is also a suitable network layer for connecting such challenged edge networks to a more regular Internet, by leveraging hop-by-hop transport functions, ICN caching and minimal application-agnostic extensions.

In earlier work, we have described a design of an improved, IEEE 802.15.4e DSME-based MAC layer for LoRa that supports packet-based communication, specifically ICN-style Interest/Data communication. Yet, RTTs can still be on the order of seconds due to the underlying power saving regime. Leveraging their work, we take an ICN-enabled LoRa subnet as a basis which is attached via an ICN forwarder on a gateway device. We developed a delay-tolerant ICN communication framework that allows connecting these LoRa sub-networks to a "regular" ICN Internet, with the following design goals:

  1. supporting IoT sensor data transmission;
  2. supporting arbitrary orders of delays, without specific assumptions of typical RTTs on other nodes on the ICN Internet;
  3. not requiring application awareness on gateway nodes;
  4. utilizing ICN-idiomatic communication to benefit from ICN principles such as accessing named data, Interest/Data semantics, caches, flow balance, etc.

We have developed interactions for IoT communication use cases that leverage bespoke (but application-agnostic) capabilities on gateway-based forwarders and the Reflexive Forwarding extensions for ICN that Dave Oran and I developed for Remote Method Invocation, RESTful communication, and IoT push data scenarios.

Our LoRa systems features two interaction patterns. First, IoT sensor data retrieval from an Internet-based consumer using Interest/Data interactions; and second, asynchronously "pushing'' data from an IoT sensor to an Internet-based consumer with pub/sub semantics.

Results

The contributions of out work are the following:

  1. The design of delay-tolerant ICN-interactions and node behavior for this constrained environment.
  2. A complete implementation of the DSME MAC layer for LoRa and our ICN protocol extensions on RIOT, serving common LoRa sensors and RIOT-based gateways.
  3. An experiment-based evaluation of the interactions on constrained IoT hardware, connected to an emulated ICN-Internet, and a comparison with vanilla ICN approaches.

In conjunction with the OS-level implementation of ICN (and extensions), DSME, and LoRa, our two protocol mechanisms for Internet consumer-initiated and LoRa producer-initiated communication exhibit high reliability and targeted completion time (compared to Vanilla ICN) when applied to the delay-prone regime.

Despite an additional round trip, our evaluations in the paper exhibit low overhead of these approaches by overcoming redundant polling. We leveraged recently proposed gateway behavior (such as RICE) and ICN protocol extensions (reflexive forwarding), the latter of which serves many other use cases beyond phoning home and could be considered a useful standard ICN feature.

References

Written by dkutscher

September 15th, 2022 at 11:09 am

Posted in Publications

Tagged with , ,

Information-Centric Long-Range Networking: Re-Imagining LoRaWAN

without comments

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

Written by dkutscher

May 17th, 2022 at 3:01 pm

Posted in Publications

Tagged with , ,

Hedge 120: Information Centric Networking

without comments

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

Written by dkutscher

March 10th, 2022 at 9:41 am

Posted in Publications

Connecting the Metaverse: In-Network Computing as Infrastructure

without comments

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

Written by dkutscher

March 8th, 2022 at 5:46 pm

Posted in Publications,Talks

Information-Centric Dataflow: Re-Imagining Reactive Distributed Computing

without comments

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

Written by dkutscher

September 21st, 2021 at 3:11 pm

Posted in Publications

Tagged with , ,

Zensur im Internet

without comments

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.

Written by dkutscher

June 23rd, 2021 at 9:56 am