Dirk Kutscher

Personal web page

Recruiting PostDocs, PhD and MPhil Students for Networked Systems Research

without comments

I am looking for PostDocs, PhD students, and MPhil students for joining my Networked Systems team at The Hong Kong University of Science and Technology in Guangzhou, China.

HKUST is a leading international research university ranked 1st by Times Higher Education Young University Rankings 2020 and 27th by QS World University Rankings 2021. Our new HKUST(GZ) campus in Guangzhou synergizes with and maintains the same academic standard as the original Hong Kong Clear Water Bay campus.

HKUST(GZ) follows a new innovative cross-discplinary approach, where computer science research interacts with hard and natural sciences, system engineering and socio-economic research.

Research Areas

I am pursuing systems research on topics such as:

We are addressing different applications such as:

  • Enabling new networked systems such as next-generation Web, network-supported AR/VR ("Metaverse");
  • Advancing the Internet and the Web to a more secure, privacy-preserving and overall more user-centric infrastructure
  • Secure and scalable edge computing;
  • Infrastructure for data science; and
  • Data-oriented IoT.

Expected Qualifications and Background

  • Ability to build software systems;
  • Knowledge in computer networking and distributed systems; and
  • Ambition to combine excellent research with building systems and artefacts that matter.

If you are interested in joining HKUST(GZ) as postdoc, postgraduate, or MPhil student please feel free to reach out to me. My e-mail address at HKUST: dku@ust.hk

Links


Written by dkutscher

October 18th, 2022 at 3:04 pm

Posted in Jobs,Posts

Tagged with ,

ACM ICN-2022 Highlights

without comments

The ACM Information-Centric Networking 2022 Conference took place in Osaka from September 19 to 21 2022, hosted by Osaka University. It was a three-day conference with tutorials, one keynote, two panel session, and paper and poster/demo presentations. The highlights (with links to papers and presentations) from my perspective were the following:

Keynote by Dave Oran: Travels with ICN – The road traversed and the road ahead

Dave Oran presented an overview of his research experience over the last ten years that was informed by many seminal research contributions on ICN and his career in the network vendor sector as well as in standards and research bodies such as the IETF and IRTF.

The keynote's theme was about disentagling the application and network layer aspects of ICN, which led to interesting perspectives on some of the previous design decisions in CCNx and NDN.

As ilustrated in the figure below, the more networking-minded ICN topics are typically connected to features and challenges of building packet-forwarding networks based on the principle of accessing named data. The actual research questions are generally not different to those of IP networks (routing, mobility etc.), but ICN provides a significant potential to re-think and often improve over the specific approaches in IP networks due to its core properties such as object security and symmetric, stateful forwarding.

Information-centric applications development in contrast is often concerned with general naming concepts, namespace design, and security features that are enabled by namespace design and application layer object security such as trust schema and provenance.

The message in Dave's talk was not that these are completely disjunct areas that should best be investigated independent of each other, but rather that the ICN's fascination and disruptive potential is based on the potential for rethinking layer boundaries and contemplating a better function split between applications, network stacks on endpoints, and forwarding elements in the network. In his talk, Dave focused on

  • the Interaction of consumers & networking producers of data;
  • routing;
  • forwarding; and
  • congestion control.

He discussed many lessons learned as well as open research and new ideas for all of these topics – please refer to the presentation slides for details.

One particularly interesting current ICN research topic is distributed computing and ICN architectures & interaction models for that. ICN's name-based forwarding model and object security provide very interesting options for simplifying systems such as microservices, RESTful services and distributed application coordination. Alluding to our work on Reflexive Forwarding, Dave offered two main lessons learned from building corresponding communication abstractions:

  1. Content fetch with two-way handshakes is a poor match for doing distributed computations.

  2. Extensions to the base protocols can give a flexible underpinning for multiple interaction models

This raises the question of the slim waist of ICN, i.e., as research progresses, what should be the minimal feature set and what is the right extensibility model?

Dave concluded his talk with a few interesting questions:

  • how can the networking insights we’ve gained from ICN protocols inform the construction of Information Centric systems and applications?

    • Whether and how to utilize name-based routing to achieve robustness and performance scaling for distributed applications?
    • Where does caching help or not help and how to best utilize caches?
    • Does pushing Names down to lower layers help latency? Resilience? Fairness?
  • How can the insights we’ve gained from applying Information Centricity in applications inform what we bother to change the network to do, and what not?

    • Do things like multipath forwarding, in-network retransmission, or reflexive forwarding actually enable applications that are hard or infeasible to do without them?
    • Is there a big win for wireless networks in terms of optimizing a scarce resource or having more robust and responsive mobility characteristics?

More details in the presentation slides

Panel: ICN and the Metaverse – Challenges and Opportunities

I had the pleasure of being in a panel with Jeff Burke (UCLA) and Geoff Houston (APNIC), moderated by Alexander Afanasyev (Florida International University) discussing Metaverse challenges and opportunities for ICN.

Questions on Metaverse and ICN

Large-scale interactive and networked AR/VR/XR systems are now referred to as Metaverse, and the general assumption is that corresponding applications will be hosted on platforms, similar to those that are employed for web and social media applications today.

In the web, the platform approach has led to an accelerated development and growth of a few popular mainstream systems. On the other hand, several problems have been observed such as ubiquitous surveillance, lock-in effects, centralization, innovation stagnation, and cost overhead for achieving the required performance.

While these phenomena may have both technical and economic root causes, we would like to discuss:

  • How should Metaverse systems be designed, and what would be important architectural pillars?
  • What is the potential for re-imagining Metaverse with information-centric concepts and protocols?
  • Would ICN enable or lead to profound architecturally unique approaches – or would protocols such as NDN be a drop-in replacement for QUIC, HTTP3 etc.?
  • What are the challenges for building ICN-based Metaverse systems, and what it missing in today's ICN platforms?

As input to the discussion, Jeff Burke and myself (together with Dave Oran) submitted two papers:

Research Directions

Jeff offered a list of really interesting research directions based on the notion that in the Metaverse, host-based identifiers and end-to-end connections between hosts would be abstracted even further away than in today’s web. Client devices would fade into the background in favor of the data supplanting or augmenting the real world. Thus, a metaverse consisted of information not associated with the physical world unless it needed to describe or provide interaction with it. The experiential semantics were viscerally information-centric, which would help to motivate the ICN research opportunities such as:

  • Persistence: The information forming a metaverse persists across sessions and users.

  • “Content” and Interoperability: Designing the relationships among metaverse-layer objects and the named packets that an ICN network moves and stores.

  • Naming and Spatial Organization: How to best integrate knowledge from research in databases and related fields where these challenges have been considered for decades.

  • Trust, Provenance, and Transactions: Using ICN to disentangle metaverse objects from the security provided by a source or a given channel of communication, with the named data representation secured at the time of publication instead.

RESTful ICN

In our paper on RESTFul ICN, Dave Oran and I asked the question: given that most web applications are concerned with transferring named units of data (web resources, video chunks etc.), 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.

Panel Discussion

The panel discussed the current socio-economic realities in the Internet and the Web and explored opportunities (and non-opportunities) for redesigns, and how ICN could be a potential enabler for that.

My personal view is that most of the potential dystopian outcomes of future Metaverse applications are independent from the enabling networking technology and the technology stack at large (security, naming etc.). It is really important to understand the actual objectives of a specific systems, i.e., who operates to which ends, similar to so-called social networks today. If the main objective is to create a more powerful advertising and manipulation platform, then such as system will exhibit yet unimaginable surveillance and tracking mechanisms – independent of the underlying network stack.

With respect to the technical design, I agree to Jeff Burke's proposed research directions. One particularly interesting question will be how to design a Information-Centric communication stack and corresponding APIs. I argued that it is not necessary to replicate existing interaction styles and protocol stacks from the TCP/IP (or QUIC) world. Instead it should be more interesting and productive to discuss the fundamentally needed interaction classes such as

  • High-performance multi-destination transfer
  • Group communication and synchronization
  • High-performance session-oriented communication with servers and peers (for which we proposed RESTful ICN).

The panel then also discussed how likely non-mainstream Metaverse systems would be adopted and whether the current socio-economic environment actually allows for that level of permissionless innovation – considering the network effects that Metaverse systems would be subjected to, much in the same way as so-called social networks.

Panel: Hard Lessons for ICN from IP Multicast?

Thomas Schmidt (HAW Hamburg) moderated a panel discussion with Jon Crowcroft (University of Cambridge), Dave Oran, and George Xylomenos (Athens University of Economics and Business) as panelists.

With the continued shift towards more and more live video streaming services over the Internet, scalable multi-destination delivery has become more relevant again. For example, the recently chartered IETF Working Group on Media over QUIC (MOQ), is addressing the need for scalable multi-destination delivery and the unavailability of IP multicast as a platform by developing a QUIC-based overlay system that essentially uses information-centric concepts, albeit in a QUIC overlay network. Such system would consist of a network of QUIC proxies, connected via individual QUIC connections to emulate request forwarding and chunk-based video data distribution. Considering the non-negligible overhead and complexity one might ask the question whether live video streaming over the Internet could be served by a better approach. Questions like this are being asked by the network service provider community (ISPs have to bear a lot of the overhead and overlay complexity) as well, for example in this APNIC blog posting by Jake Holland titled Why inter-domain multicast now makes sense.

This panel was inspired by a statement paper submitted by Jon Crowcroft titled [Hard lessons for ICN from IP multicast (https://dl.acm.org/doi/10.1145/3517212.3558086). In this brief statement, Jon traced the line of thought from Internet multicast through to Information Centric Networking, and used this to outline what he thinks should have been the priorities in ICN work from the start.

The statement paper discusses a few problems with IP multicast that have been largely acknowledged such as difficulties in creating viable business models, unsolved security problems such as IP multicast being used as a DDOS platform, and interdomain multicast that proven difficult to establish due multicast routing scaling problems and the lack of robust pricing models. The second part of the paper is then some ICN work that has been addressing some of the mentioned issued.

The paper gave rise to an interesting and controversial discussion at the panel. The most important point is IMO to characterize ICN communication model correctly: it is correct that the combination of stateful forwarding, Interest aggregation, and caching enables an implicit multi-destination delivery service. It is implicit, because consumers that ask for the same units of named data within a time frame at the order of the network RTT will send equivalent Interest messages so that forwarders can multicast the data delivery to the faces they received such Interests from. In conjunction with opportunistic (or managed) caching by forwarders this would enable a very elegant multi-destination delivery services that can even cater to a wider variation of Interest sending times, as "late" Interest would be answered from caches.

This is a different service model compared to the push-based IP multicast model. ICN does not provide such as service in the first place, but is just applying its regular receiver-driven mode of operation which elegantly works well in the case of multiple consumers asking for the same data. It is probably fair to say that the ICN model caters to media-delivery use cases (one stream delivered to multiple consumers) but does not try to provide the more general IP multicast service model (Any Source Multicast). However, by extension, the ICN approach could be applied to multi-source scenarios as well – the system would build implicit delivery trees from any source to current consumers, without requiring extra machinery.

With this, if you like, simpler service model, ICN does fundamentally not inherit many of the problems that prohibit IP multicast in the Internet: the system is receiver-driven which simply eliminates DDOS threats (on the packet level). It is also not clear, whether ICN would need anything special to provide this service in inter-domain settings (except for general ICN routing in the Internet, which is a general,
but different research question).

Acknowledging this conceptual and practical difference, there are obviously other interesting research questions that ICN multi-destination delivery entails, for example performance and jitter reduction in the presence of caching and other transport questions.

Overall, a good time to talk about multi-destination delivery and to keep thinking about missing pieces and potential future work in ICN.

Enabling Distributed Applications

One paper presentation session was focused on distributed applications – a very interesting and relevant ICN research area. It featured three great papers:

SoK: The evolution of distributed dataset synchronization solutions in NDN

This paper by Philipp Moll, Varun Patil, Lan Wang, and Lixia Zhang systemizes the knowledge about distributed dataset synchronisation in ICN, or Sync in short, which, according to the authors, plays the role of a transport service in the Named Data Networking (NDN) architecture. A number of NDN Sync protocols have been developed over the last decade. For this paper, they conducted a systematic examination of NDN Sync protocol designs, identified common design patterns, revealed insights behind different design approaches,
and collected lessons learned over the years.

Sync enables new ways of thinking about coordination and general communication in distributed ICN systems, and I encourage everyone to read this for a good overview of the different proposed systems and their properties.

There are also some open research questions around Sync, such as large-scale applicability, alternative to using Interest multicast for discovery and more – a good topic to work on!

DICer: distributed coordination for in-network computations

This paper by Uthra Ambalavanan, Dennis Grewe, Naresh Nayak, Liming Liu, Nitinder Mohan, and Jörg Ott is a nice product of the Piccolo project that had the pleasure to set up and co-lead.

Application domains such as automotive and the Internet of Things may benefit from in-network computing to reduce the distance data travels through the network and the response time. Information Centric Networking (ICN) based compute frameworks such as Named Function Networking (NFN) are promising options due to their location independence and loosely-coupled communication model.

However, unlike current operations, such solutions may benefit from orchestration across the compute nodes to use the available resources in the network better. In this paper, the authors adopted the State Vector Synchronization (SVS), an application dataset synchronization protocol in ICN, to enhance the neighborhood knowledge of in-network compute nodes in a distributed fashion. They designed distributed coordination for in-network computation (DICer) that assists the service deployments by improving the resolution of compute requests.

Kua: a distributed object store over named data networking

This paper by Varun Patil, Hemil Desai, and Lixia Zhang decribes a distributed object store in NDN.

Applications such as machine learning training systems or log collection generate and consume large amounts of data. Object storage systems provide a simple abstraction to store and access such large datasets. These datasets are typically larger than the capacities of individual storage servers, and require fault tolerance through replication. This paper presents Kua, a distributed object storage system built over Named Data Networking (NDN).

The data-centric nature of NDN helps Kua maintain a simple design while catering to requirements of storing large objects, providing fault tolerance, low latency and strong consistency guarantees, along with data-centric security.

ICN Applications and Wireless Networking

The session on ICN Applications and Wireless Networking features four papers:

N-DISE: NDN-based data distribution for large-scale data-intensive science

This paper by Yuanhao Wu, Faruk Volkan Mutlu, et al. describes an NDN for Data-Intensive Science Experiments (N-DISE).

To meet unprecedented challenges faced by the world’s largest data- and network-intensive science programs, the authors designed and implemented a new, highly efficient and field-tested data distribution, caching, access and analysis system for the Large Hadron Collider (LHC) high energy physics (HEP) network and other major science programs. They developed a hierarchical Named Data Networking (NDN) naming scheme for HEP data, implemented new consumer and producer applications to interface with the high-performance NDNDPDK forwarder, and buildt on recently developed high-throughput NDN caching and forwarding methods.

The experiemts in this paper include delivering LHC data over the wide area network (WAN) testbed at throughputs exceeding 31 Gbps between Caltech and StarLight, with dramatically reduced download time.

Building a secure mHealth data sharing infrastructure over NDN

In this paper Saurab Dulal, Nasir Ali, et al. describes an NDN-based mHealth system called mGuard.

Exploratory efforts in mobile health (mHealth) data collection and sharing have achieved promising results. However, fine-grained contextual access control and real-time data sharing are two of the remaining challenges in enabling temporally-precise mHealth intervention. The authors have developed an NDN based system called mGuard to address these challenges. mGuard provides a pub-sub API to let users subscribe to real-time mHealth data streams, and uses name-based access control policies and key-policy attribute-based encryption to grant fine-grained data access to authorized users based on contextual information.

Delay-tolerant ICN and its application to LoRa

I have co-authored this paper together with Peter Kietzmann, José Alamos, Thomas C. Schmidt, and Matthias Wählisch.

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 paper on "Delay-Tolerant ICN and Its Application to LoRa" 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.

iCast: dynamic information-centric cross-layer multicast for wireless edge network

This paper by Tianlong Li, Tian Song, Yating Yang, and Jike Yang presents iCast, short for dynamic information-centric multicast, to enable dynamic multicast in the link layer.

Native multicast support in Named Data Networking (NDN)
is an attractive feature, as multicast content delivery can reduce the redundant traffic and improve the network performance, especially in wireless edge networks. With their visibility into Interest and Data names, NDN routers automatically aggregate the same requests from different end hosts and establish network-layer multicast. However,
the current link-layer multicast based on host-centric MAC address management is inflexible. Consequently, supporting NDN dynamic multicast with the current link-layer architecture remains a challenge.

iCast enables dynamic multicast in the link layer based on three main contributions:

  1. iCast integrates NDN native multicast with the host-centric link layer while maintaining the host-centric properties of the current link layer.
  2. iCast achieves per-packet dynamic multicast in the link layer, and the authors further propose a hash-based iCast variant for dynamic connection.
  3. iCast has been implemented in a real testbed, and the evaluation results show that iCast reduces up to 59.53% traffic compared with vanilla NDN. iCast bridges the gap between NDN multicast and the host-centric link-layer multicast.

Written by dkutscher

September 27th, 2022 at 3:29 pm

Posted in Events

Tagged with , ,

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 , ,

Joined The Hong Kong University of Science and Technology (Guangzhou)

without comments

HKUST(GZ) logo

On September 1st 2022, I have joined the Hong Kong University of Science and Technology in Guangzhou –
HKUST(GZ)
. HKUST is a world-class internationally-minded research university that was founded in 1991 in Clear Water Bay, Hong Kong, with a track record of excellent research and teaching.

In 2022, HKUST has opened a new campus in Guangzhou, across the border in China's Guangdong province:
HKUST(GZ).

The new campus is complementing HKUST's existing Clear Water Way campus and is intended for developing new cross-disciplinary programs, in four hubs:

  • Information Hub: to address global challenges arising from human interactions with information and technology in today's era of digital transformation.
  • Function Hub to focuss on basic elements in hard and natural sciences, and to seek advanced and sustainable solutions to address real-world problems.
  • Systems Hub: to develop scientific knowledge, offering engineering methodologies, and to solve cross-disciplinary problems, e.g., in Bioscience & Biomedical Engineering.
  • Society Hub: to resolve socio-economic issues and contribute to the knowledge economy in a networked society and rapidly changing world.

I am working in the Internet of Things Thrust, led by Prof. Danny Tsang, of the Information Hub, led by Prof. Fugee Tsung. The other Thrusts in the Information Hub are:

My research focus will be on:

  • Distributed Computing and Networking (Compute-First Networking, Computing in the Network)
  • Information-Centric Networking (ICN)
  • Internet architecture and decentralized communication

If you are interested in joining HKUST(GZ) as faculty, postdoc, postgraduate, or MPhil student please feel free to reach out to me. My e-mail address at HKUST: dku@ust.hk

Written by dkutscher

September 12th, 2022 at 7:03 am

Posted in personal

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 , ,

MAVERIC: In-Network Computing for 5G/6G Campus Networks

without comments

Together with our partners Xantaro, Naval Vessels Lürssen, and the University of Applied Sciences Augsburg, we have started a new project on In-Network Computing for 5G/6G campus networks. The MAVERIC project will develop a mobile 5G campus network system with a special focus on automated deployment, monitoring as well as flexible and digitally sovereign in-network computing. The main use cases within the project are processes and tasks on ship yards. This environment is particularly harsh and has very high requirements regarding availability, security and confidentiality.

The MAVERIC project is sponsored by the German Federal Ministry for Economic Affairs and Climate Action (BMWK).

Written by dkutscher

April 12th, 2022 at 5:48 pm

Posted in Projects

Tagged with , , ,

Information-Centric Networking Research Group at IETF-113 Summary

without comments

The Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF) met during the 113th meeting of the Internet Engineering Task Force (IETF) that took place in Vienna from March 19th to March 25th 2022. IETF-113 was the IETF's first hybrid meeting with onsite and remote participants.

Presentation material and minutes are available online, and there is a full recording on youTube. I am summarizing the meeting below.

Edmund Yeh: NDN for Data-Intensive Science Experiments

Edmund Yeh (Northeastern University) presented the NSF-funded project NDN for Data-Intensive Science Experiments (N-DISE), a two-year inter-disciplinary project with participants from Northeastern, Caltech, UCLA, and Tennessee Tech that collaborates with the Large Hadron Collider (LHC), genomics researchers, and the NDN project team.

N-DISE is building data-centric ecosystem to provide agile, integrated, interoperable, scalable, robust and trustworthy solutions for heterogeneous data-intensive domains, in order to support very data-intensive science applications through an NDN-based communication and data sharing infrastructure. The LHC high energy physics program represents the leading target use case, but the project is also looking at BioGenome and other human genome projects as future use cases.

In many data-intensive science applications, data needs to distributed in real-time, archived, retrieved by multiple consumers etc. Within one data centers, but even more so in geographically distributed scenarios, this could lead to a signficant amount of duplicated transmissions with legacy system architectures. N-DISE would leverage general ICN features and concepts such as location-independent data naming, on-path caching and explicit replication through data repos to dramatically improve the efficiency but also to reduce the complexity of such data management systems and their applications.

The general approach of the N-DISE project is to leverage recent results in high-speed NDN networking such as ndn-dpdk to build a data science support infrastructure for petascale distribution, which involves research in high-througput forwarding/caching, the definition of container-based node architectures, FPGA acceleration subsystems and SDN control. The goal is to deliver LHC data over wide area networks at throughputs of approximately 100 Gpbs and to dramatically decrease download times by using optimized caching.

From an NDN perspective, the project provides several interesting lines of work:

  • Deployment architectures (how to build efficient container-based N-DISE nodes);
  • WAN Testbed creation and throughput testing;
  • Optimized caching and forwarding;
  • Congestion control and multi-path forwardind; and
  • FPGA acceleration.

There are several interesting ideas and connections to ongoing ICN research in N-DISE. For example, as people start building applications for high-speed data sharing but also distributed computing, the question of container-based ICN node architectures arise, i.e., how to enable easy cloud-native deployment of such systems without compromising too much on performance.

Another interesting aspect is congestion control in multi-path forwarding scenarios. Existing technologies such as Multipath TCP and Multipath QUIC are somewhat limited with respect to their ability to use multipath resources in the network efficiently. In ICN, with its different forwarding model multipath forwarding decisions could be made hop-by-hop, and consumers (receiving endpoints) could be given greater control over path selection. For example:

Cenk Gündoğan: Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic

Cenk Gündoğan of HAW Hamburg presented an update of draft-gundogan-icnrg-ccnx-timetlv, a proposal for an alternative logarithmic encoding of time values in ICN (CCNx) messages.

The motivation for this work lies in constrained networking where header compression as per RFC 9139 (ICNLoWPAN) would be applied and more compact time encoding would be desirable. The proposed approach would allow for a compact encoding with dynamic ranges (as in floating point arithmetics), but imposes challenges with respect to backwards compatibility.

ICNRG is considering adopting this work as a research group item to find the best way for updating the current CCNx specifications in the light of these questions.

Dave Oran: Ping & Traceroute Update

Dave Oran presented the recent updates to two specifications:

In IP, fundamental and very useful tools such as ping and traceroute were created years after the architecture and protocol definitions. In ICN there is an opportunity to leverage tooling at an earlier phase – but also to reason about needed tools and useful features.

ICN Ping provides the ability to ascertain reachability of names, which includes

  • to test the reachability and operational state of an ICN forwarder;
  • to test the reachability of a producer or a data repository;
  • to test whether a specific named object is cached in some on-path CS, and, if so, return the administrative name of the corresponding forwarder; and
    • to perform some simple network performance measurements.

ICN Traceroute provides ability to ascertain characteristics (transit forwarders
and delays) of at least one of the available routes to a name prefix, which includes

  • to trace one or more paths towards an ICN forwarder (for troubleshooting purposes);
  • to trace one or more paths along which a named data of an application can be reached;
  • to test whether a specific named object is cached in some on-path CS, and, if so, trace the path towards it and return the identity of the corresponding forwarder; and
  • to perform transit delay network measurements.

Both drafts completed Research Group Last Call in January 2022 and evoked some feedback that has now been addressed (see presentation for details). ICNRG will transfer these drafts to IRSG review and subsequent steps in the IRTF review and publication process soon.

Dave Oran: Path Steering Refresher

Dave Oran presented a refresher of a previously presented specification of Path Steering in ICN (draft-oran-icnrg-pathsteering). Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management.

In ICN, communication is inherently multi-path and potentially multidestination. But so far there is no mechanism for consumers to direct Interest traffic onto a
specific path, which could lead to
– Forwarding Strategies in ICN forwarders can spray Interests onto various paths;
– Consumers have a hard time interpreting failures and performance glitches;
– Troubleshooting and performance tools need path visibility and control to find problems and do simple measurements.

ICN Path Steering would enable

  • Discovering, monitor and troubleshoot multipath network connectivity based on names and name prefixes:
    • Ping
    • Traceroute
  • Accurately measure a performance of a specific network path.
  • Multipath Congestion control needs to:
    • Estimate/Count number of available paths
    • Reliably identify a path
    • Allocate traffic to each path
  • Traffic Engineering and SDN
    • Externally programmable end-to-end paths for Data Center and
      Service Provider networks.

Briefly, Path Steering works by using a Path Label (as an extension to existing protocol formats, see figure) for discovering and for specifying selected paths.

The technology would give consumers much more visibility and greater control of multipath usage and could be useful for many applications, especially those that want to leverage path diversity, for example high-volume file transfers, robust communication in dynamically changing networks, and distributed computing.

Dirk Kutscher: Reflexive Forwarding Re-Design

Dave Oran and I recently re-design a scheme that we called Reflexive Forwarding and that is specified in draft-oran-icnrg-reflexive-forwarding.

Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an Interest-Data exchange in the case of the two protocols noted above).

A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint.

This specification proposes a Reflexive Forwarding extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609.

Example: RESTful communication over ICN

In today HTTP deployments, requests such as HTTP GET requests are conceptionally stateless, but in fact they carry a lot of information that would allow server to process these requests correctly. This includes regular header fields, cookies but also input parameters (form data etc.) so that requests can become very large (sometimes larger than the corresponding result messages).

It is generally not a good idea to build client-server systems that require servers to parse and process a lot a client-supplied input data, as this could easily be exploited by computational overload attacks.

In ICN, in addition, Interest message should not be used to carry a lot of "client" parameters as this could lead to issues with respect to flow balance (congestion control schemes in ICN should work based on DATA message volume and rate), but would also force forwarders to store large Interest messages and could potentially even lead to Interest fragmentation, a highly undesirable consequence.

Reflexive Forwarding aims at providing a robust ICN-idiomatic way to transfer "input parameters", by enabling the "server side" to fetch parameters using regular ICN communication (Interest/Data). When doing so, we do not want to give up important ICN properties such as not requiring consumers (i.e., the "clients") to reveal their source address – a useful feature for enable easy consumer mobility and some form of privacy.

Reflexive Forwarding Design

Our Reflexive Forwarding scheme addresses this by letting the consumer specify a tempory, non-globally-routable prefix to the network and the producer that would allow the producer to get back to the consumer through Reflexive Interests for fetching the required input parameters at the producer's discretion. The figure above depicts the high-level protocol operation.

Our new design leverage tempory PIT (Pending Interest Table) state in forwarders and PIT Tokens (hop-by-hop protocol fields in NDN and CCNx) that would allow forwaders, to map Reflexive Interests to PIT entries of the actual Interest and thus forward the Reflexive Interest correctly, on the reverse path.

Potential Applications

Potential applications include

  • RESTful communication, e.g., Web over ICN;
  • Remote Method Invocation;
  • Phone-home scenarios; and
  • Peer state synchronization.

For example, we have used a previous design of this scheme in our paper RICE: Remote Method Invocation in ICN that leveraged Reflexive Forwarding for the invocation and input parameter transmission as depicted in the figure above.

Reflexive Forwarding requires relativly benign to ICN forwarder and endpoint behavior but could enable many relevant use cases in an ICN idiomatic way, without requiring large layering overhead and without giving important ICN properties.

Written by dkutscher

April 1st, 2022 at 2:36 pm

Posted in IRTF

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