Tangle Centric Networking (TCN)

08/15/2021 ∙ by Christopher Scherb, et al. ∙ Universität Basel Bosch 0

Today's Internet is heavily used for multimedia streaming from cloud backends, while the Internet of Things (IoT) reverses the traditional data flow, with high data volumes produced at the network edge. Information Centric Networking (ICN) advocates against a host-centric communication model which is promising for distributed edge computing environments and the execution of IoT applications in a decentralized fashion. By using naming schemes, data is tightly coupled to names instead of hosts which simplifies discovery and access to data and services. However, the tight coupling challenges network performance due to additional synchronization overhead of large data volumes and services. We present Tangle Centric Networking (TCN) – a decentralized data structure for coordinated distributed applications and data exchange following principles of ICN. TCN can react on data and service changes and update them accordingly in network nodes, provide distributed data structures and enable cooperative work on the same data without huge overhead by using Tangles for coordination. We implemented TCN in simulations and evaluated the concept against a base line scenario.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The Internet of Things (IoT) is reversing the data flow from traditional cloud-to-edge to edge-to-cloud with much of the data produced at the edge. While the number of IoT devices will double until 2025 up to 75 billion Forbes (2021), the data produced by these devices at the edge require processing upfront before sending it towards cloud backends (e.g., Moustafa et al. (2017)). Such a paradigm shift enables novel classes of distributed applications which are deployed in challenging environments such as highly connected automated driving, manufacturing automation or gaming. Examples include applications demanding for timely information sharing, often to multiple consumers, which cannot be satisfied by classic cloud-based solutions.

The Edge Computing (EC) paradigm is concerned about to supporting these classes of applications. EC brings computational resources, storage and services from the cloud backend to the edge of the network and therefore, closer to the data origin and its consumers (e.g., Bonomi et al. (2012)). However, most of today’s network architectures are still based on a host-oriented communication model, interconnecting components with each other such as the Internet Protocol (IP) technology stack. The model challenges the network at many levels such as management and orchestration of data and services, i.e., in mobile scenarios. As a result, additional frameworks are introduced to manage the overhead in the communication infrastructure such as ETSI OSM European Telecommunications Standards Institute (2021) for management of services in upcoming 5G cellular deployments. Instead, native network-layer resolution of desired data and services avoids additional communication overhead (e.g., DNS) and has the potential to reduce response times significantly.

Information Centric Networks (ICN) present a promising solution for novel classes of distributed applications in IoT deployments (e.g., Amadeo et al. (2016)). Based on a loosely coupled communication model, ICNs use location-independent, unique content identifiers such as naming schemes for discovering and accessing data in the network Jacobson et al. (2009). This approach couples data to an identifier instead of the host and thus avoids resolution conflicts. It allows mobility support by nature, while not maintaining network addresses of hosts and also facilitates additional features such as in-network processing and caching of data. Therefore, it can be a great fit to provider-agnostic distributed applications in IoT scenarios.

As ICNs target to support a wide range of distributed applications, there are special classes of application data which challenges data discovery and management, for example, data changing at frequent intervals (e.g., a temperature sensor) as well as large volumes of data (e.g., video stream of a surveillance camera). In order to simplify the access, ICNs propose the concept of Manifests (e.g., FLIC Tschudin and Wood (2016)). Manifests describe properties of a data item including a list of content identifiers for smaller application specific chunks.

While Manifests simplify the access to special classes of application data, it introduces a challenge on the handling frequent changing data items. Every time a data item changes, a new version of the item is created and published under a new unique content identifier. However, the tight coupling of data to immutable content identifiers results in frequent re-creation of the entire Manifest. This design decision introduces the problem on how to select and announce new versions of data in the network to avoid collisions. It either requires centralized name resolution systems managing these identifiers (e.g., NDNS Afanasyev et al. (2017)), mechanisms to achieve consensus about identifiers (e.g., synchronization across nodes), or the same data is published using different identifiers, unnecessarily occupying resources, and thus, decreases network efficiency.

To address these limitations, distributed data structures offer data replication across the network. Examples include Distributed Hash Tables or Conflict-free replicated data types (CRDTs) Shapiro et al. (2011). In IoT scenarios, distributed ledger technologies have gained attention in the research community in recent years. An example to highlight is IOTA IOTA Foundation (2020), offering a lightweight solution to represent data in form of Tangles.

In this paper, we propose Tangle Centric Networking (TCN) – a network level consensus and synchronisation extensions for ICNs using Tangles Popov (2018). Implement as directed acyclic graph (DAG), Tangles are aligned to the proposed structure of existing Manifest solutions like FLIC Tschudin and Wood (2016), while promising additional features such as extensibility and distributed consensus.

The contributions of the paper are:

  • introduction of a concept of Tangles in ICNs for network level consensus and efficient management of data objects

  • implementation and evaluation of TCN using Named Data Networking (NDN) Zhang et al. (2014) and the PSync Zhang et al. (2017) protocol showing performance improvement in data retrieval

  • discussion of further potentials and open research directions

The remainder of the paper is structured as follows: Section II introduces a use case scenario. Section III provides the related work, while Section IV introduces the concept of TCN and certain architectural aspects in Section V. Section VI presents the implementation and evaluation of TCN, followed by a discussion on the results and open research directions in Section VII. Finally, we conclude the paper in Section VIII.

Ii Use Case Scenarios

Distributed edge computing environments enable novel classes of application scenarios in different IoT domains. Examples include smart factories, healthcare systems, or connected and automated driving (e.g., Buyya and Dastjerdi (2016)). In this paper, we consider a use case from the domain of connected and automated driving, based on the special characteristics of the scenario.

Figure 1: The electronic horizon in a distributed edge environment. Data from different sources are collected and processed close to the origin, creating an environmental model used by automated driving logic.

ii.1 Automotive: Electronic Horizon for Highly Automated Driving

It is evident that automated driving will rely on information from in-vehicle systems as well as data sources deployed outside the vehicle Wang et al. (2019). It is expected that driving logic in automated driving vehicles will take in several inputs ranging from built-in sensor data streams to context and external information (incl. road topology, localization, position of obstacles and moving objects, odometry, acceleration data, traffic volumes, etc.). The characteristics of such data are quite different in terms of volumes, popularity as well as validity, most of it generated at the edge of the communication infrastructure (cf. Moustafa et al. (2017)).

Based on all information, an environmental model is created periodically – e.g., the Local Dynamic Map (LDM) Andreone et al. (2010) – serving as an input to the driving logic to further improve the driving quality. Finally, the driving logic computes the output for steering the vehicle (steering angle, inputs to the gas & brake pedals, switching signal lamps etc.)

On the road towards fully automated driving, the electronic horizon describes a purely cloud-based virtual vehicle sensor using pre-defined data sources. These sources include map data, vehicle’s mobility model as well as additional data regarding the stretch of road ahead during a journey. As it is already available as a product for certain high class vehicle models (e.g., dSPACE GmbH (2010); GmbH (2020)), it forms a base line scenario for upcoming driving logic in automated driving vehicles.

Figure 1 illustrates the electronic horizon in a distributed edge deployment. The fusion of all data and computation of the model require a high amount of computing power. Instead of sending all the data towards cloud backends, data can be collected, processed and augmented with other information by compute nodes on the delivery path close to its origin (cf. Grewe et al. (2017)). Such approach is promising to reduce the massive amount of data to be transmitted towards cloud backends (see reverse CDN Moustafa et al. (2017)), while increasing the overall quality of information for such scenario (e.g., enhance information from camera streams nearby).

ii.2 Challenges from the Use Case

The presented use case introduces several challenges. The data to be collected is of different types (e.g., large vs. small volumes, popularity, etc.), while dynamically generated content from compute nodes challenges efficient dissemination. From a communication and computing infrastructure perspective, data flows are reversing from downstream of cloud backends, towards upstream from devices close to the vehicle. The scenario challenges to understand data points as well as to put data and computations into the right context (linking together) to be processed at the network edge. From a vehicle perspective, the scenario challenges dynamically generated data and discovers the closest compute node by taking the mobility aspect of the vehicle into account.

Iii Background & Related Work

As we move toward a distributed edge computing environment, computation-centric network architecture defines a need to support decentralized and distributed computations. The following sections will present some background and related work.

iii.1 Information Centric Networking

ICN describes a paradigm which puts data as the first class citizen in the network by separating content from its physical location. We refer the term ICN to the network principles introduced by Jacobson et al. Jacobson et al. (2009) including architectures such as Named Data Networking (NDN) Zhang et al. (2014). By changing the addressing scheme using content identifiers (e.g., hierarchical naming schemes), ICN achieves a loosely-coupled communication model directly on the network layer. This is in stark contrast to host-centric deployments where devices need to connect to specific nodes using their IP address. Therefore, ICNs are promising for data transport in deployments at the network edge as well as in IoT environments as there is no need for the network to track the location of individual nodes Amadeo et al. (2016); Grewe et al. (2017).

Content in ICN is represented by so-called Named Data Objects (NDO) that have identifiers, but that are usually not associated to a single or specific physical node in the network. To transfer large volumes of data in an ICN, NDOs are structured into smaller chunks to fit into the maximum transmission unit of the underlying network. ICNs provide several solutions to discover the identifiers of chunks of a particular NDO including Manifest (e.g., FLIC Tschudin and Wood (2016)) or DNS-like resolution system such as NDNS Afanasyev et al. (2017). For example, FLIC is build like a UNIX directory. From a root manifest (in UNIX terms: root-directory) it points to chunks (in unix terms: files) and to the next manifests (in UNIX terms: directories). Each manifest can contain further manifests or chunks. Thus, FLIC represents a tree, where manifests are inner nodes and chunks are trees. This is a very efficient data structure to find certain chunks, since the search time is reduces from linear to logarithmic. However, to support the execution of distributed application on top of ICNs, any changes to data requires updates of the NDO descriptions to provide access to vital data. For example, FLIC Manifests often have to be re-created entirely every time a change to a NDO happens, since each of the manifests contains signatures of the chunks/other manifests it is pointing to.

Addressing this issue, distributed data synchronization protocols have been proposed in the literature to support multi-party communication in ICNs (cf. Shang et al. (2017)). Examples include ChronoSync Zhu and Afanasyev (2013), VectorSync or PSync Zhang et al. (2017) featuring different design rationals in naming schemes, and state propagation. However, as we move towards edge computing environment, these solutions have not been evaluated in the context of compute-centric networking architectures.

iii.2 Distributed Storage & Ledger

In distributed systems, the CAP theorem (also called Brewer’s Theorem) poses that a system can have only two of three desirable properties: consistency, availability, and partition tolerance Gilbert and Lynch (2002). However, trade-offs can be achieved by explicitly handling partition tolerance in order to optimize consistency. For example, CFN uses CRDTs to describe the compute graph the platform should execute Król et al. (2019). However, CRDTs only guarantee eventual consistency demanding for global consistency - the entire data structure has to be updated in case of changes Shapiro et al. (2011). In recent years, distributed ledger describes a technological infrastructure representing consensus by allowing to access, validate and record data across multiple parties in a distributed fashion Swan (2015). The Blockchain Swan (2015) implements a distributed, append-only structure consisting of connected blocks. Examples based on the technology include Bitcoin Nakamoto (2019) or Ethereum Foundation (2021). In the context of compute-centric architectures, the SPOC Michał Król and Ioannis Psaras (2018) approach uses Ethereum to record outsource computations, executed by 3rd party nodes in the infrastructure, able to validate changes.

Instead of recording entries as an append-only structure of connected blocks, the Tangle Popov (2018) technology, which is the data structure behind IOTA IOTA Foundation (2020), implements a directed acyclic graph (DAG) for storing transactions. Every new transaction has to approve at least two previous transactions to be recorded in the Tangle. A tip is a not yet approved block. Thereby, the tips selection algorithm chooses two tips that should been approved. The algorithm makes sure that tips are chosen in a way, that the tangle will reach convergence quickly.

Based on this concept, Tangles build their consensus development based on the number of accepted predecessors in the Tangle, while not relying on a proof-of-work concept (e.g., in Blockchain) or on a certain time interval (e.g., as in CRDTs). Figure 2 illustrates the differences between the Blockchain and Tangle technology. If status changes happen, nodes can still operate on old data as they are not immediately evicted from the Tangle structure, allowing for situations in which the result of the operation might be validated.

Figure 2: Illustration of the characteristics of the distributed, append-only data structure of Blockchain and Tangles.

Iv Tangle Centric Networking Architecture

The tight coupling of content identifiers challenges the introduction, and thus, the discovery of newly generated content in ICNs and compute-centric approaches as well (cf. Section I). In order to address this problem, we propose Tangle Centric Networking (TCN).

TCN enhances the design principles of Interest-based ICN architectures (e.g., NDN) with the Tangle technology Popov (2018) to improve data retrieval of content in ICNs (see Section III). Like in ICNs, TCN uses naming schemes to request for NDOs and supports Manifests to query the network for large objects. Large objects are divided into chunks, while each chunk is associated with a content identifier, managed in a Manifest (e.g., FLIC Tschudin and Wood (2016)).

In TCN, the Manifest of each NDO is represented as a Tangle, associated with a content identifier that can be requested within an ICN. Each Tangle represents a set of chunks of a NDO (or the entire NDO) in a structured way. In case a change happens to a NDO, and therefore, to a set of chunks of the NDO, the characteristics of a Tangle allows network participants to acknowledge to the latest status of it and thus, to achieve consensus. As a result, Tangles in TCN represent a common structure handling all versions of a particular NDO. It allows a consumer to selectively request for different versions of a NDO, without resolving several identifiers for each Manifest as required in FLIC. Furthermore, the special update and synchronization characteristics of Tangles simplify the handling of changes of NDOs and is promising to improve the performance of updating Manifest.

iv.1 The Design of Tangles in TCN

A Tangle in TCN is represented by two elements: A core element – representing a part of a NDO Manifest, containing a list of names of associated chunks, and an acknowledgement element – representing a meta-information block to assist consensus.

The core element stores the name as well as the hash of each associated chuck, used by nodes to query the network for data. Each Tangle is signed by the producing node using digital signatures to ensure data integrity and authenticating the originator of the Tangle. In order to point to the next subsequent core element of the Tangle which contains the information to the next chunks, the element maintains the hash value of the previous core element and the hash value of at least one further chunk to form the initial Tangle. As a result, the Tangle created is represented as a DAG of elements (see Figure 3). The verification degree of a core element is the number of incoming edges of acknowledgements, while a Tangle tip describes an element with no incoming edges. By referring to the precedent chunks instead of following ones (e.g., as designed in BlockChain Swan (2015)), a data flow driven processing of Tangles is ensured by design. Chunks within a Tangle are already available in the network to be requested by consuming nodes, while subsequent chunks are not yet created.

As core elements of a Tangle might get created and appended to the overall Tangle structure in irregular time intervals, a mechanism to model consensus is required. To model it, an acknowledgement element describes a meta-information block associated with each core element (see Figure 3). Every time a core element is synchronized and accepted by another node in the network, an acknowledgement element for the particular core element is appended by the synchronizing node. This way, a single node can only append one acknowledgement per appended block. Thus, with the knowledge how many nodes are synchronizing, a node knows when a consensus was established for a block. In TCN, we do not need a tip selection algorithm as in IOTA, since the places where a node can append data are already tightly restricted, since a new version can only be appended on the previous version and acknowledgements can only be appended on the new block in addition to at least one randomly chosen other block. Therefore, the Tangle necessarily represents the logical structure of the data.

An example of a data exchange in TCN looks as follows: a client requests for a large NDO using an ICN Interest packet and the content identifier of the NDO. As it is a large NDO separated into several chunks, the client receives a Manifest file representing a part of a Tangle. The client uses the chunk information provided in the Manifest to request for each chunk of the NDO. Tangles are stored in a dedicate Manifest Synchronization Table (MST) data structure instead of being handled as a typical content object in the ICN forwarding plane. This has two reasons: (i) it allows to identify and operate on Tangles (e.g., synchronize its content due to updates), and (ii) avoids eviction of Tangles in the node cache according to its cache management policy. When a forwarder stores a Manifest representing a core element of a Tangle in its MST

, it will append an acknowledgement block to each element that it could verify. Verification takes place during forwarding the data chunk by comparing the hash value of the signature of the chunk packet with the signature hash value present in the Manifest. The verification degree of a core element is the number of incoming edges, which represents the number of nodes which acknowledged to a core element. The moment a forwarder will append an acknowledgement to a core element, the other nodes storing the manifest will synchronize the change. We refer to this situation as Tangle synchronization. The more forwarder acknowledge to a core element the better in order to reach consensus on the Tangle.

Figure 3: A Tangle consisting of core (green) and acknowledgement elements (red) which identify chunks (gray) by hashes. Verification degree is the weight of the edges.

iv.1.1 Linear vs. Tree Tangles

Tangles can be modeled in different ways. Besides modeling a Tangle in a linear fashion where one element follows each other, the concept of Tangles also allows to model a hierarchical tree.

Instead of creating one ICN Manifest file describing the entire Tangle, e.g., by listing all core and acknowledgement elements in one Manifest, a publisher can create a Manifest file for each core and its associated acknowledgement element. As a result, elements of a Tangle are treated and transferred in the network as NDOs in ICN, allowing for new opportunities to handle data in TCN.

This is an important aspect, as additional nodes can contribute to the overall Tangle besides the original content publisher. For example in the electronic horizon use case (cf. Section II.1), other nodes can improve the overall quality of the use case application by updating the Tangle with additional data sources dynamically (e.g., feeds of cameras deployed at buildings recording a hazardous situation in the vicinity). Being able to verify how many different nodes participated in the Tangle so far, either by creating new core elements or acknowledgements, a node knows how well certain NDOs are verified and which elements have been created by the originator and which parts have been appended by other nodes (e.g., Figure 3).

iv.1.2 Handling Versions of Data in TCN

According to the design rationale of immutable content identifiers in ICNs (e.g., Zhang et al Zhang et al. (2014)), any change of the payload of a NDO results in a new version of the NDO, announced in the network using a new content identifier. In order to be able to request for different versions, TCN’s Tangles support versioning by appending new versions of individual chunks to the existing Tangle. Instead of re-creating the entire Manifest, i.e., as in FLIC Tschudin and Wood (2016), only the changed elements within a Tangle need to be updated, pointing to the new version of the NDO. As a result, TCN allows to represent data in the network in a distributed database fashion instead of a simple key-value store.

However, a new version cannot be accepted without the consensus of other nodes in the network. Whenever a change happens in a Tangle, a new version is created and appended to the Tangle, visible as history for all other nodes. Similar like in Blockchain, all transactions on the Tangle are stored within the Tangle itself. While a Blockchain represents a single decentralized data structure containing all content, replicated by every participant, TCN introduces decentralized data structures on each NDO. As a result, the overhead of synchronizing new content is expected to be fewer compared to a Blockchain structure. Furthermore, Tangles provide more flexibility in selecting the content to be synchronized. Staled information of a Tangle can be dropped by the publisher (e.g., non-valid version), instead of replicating all existing content as prescribed by a Blockchain.

In order to get a new version accepted in the network, a producer needs to select two core elements of a Tangle to append the new version to (cf. Figure 4). We recommend that the primary element is selected in a semantic manner: if a new version of a chunk is added, it has to be appended to the block containing the previous version. If a chunk is replaced entirely by a new block, it has to be appended to the end of the Tangle representing the latest version. The secondary element is selected randomly as each element at least has to point to two predecessors. A random selection minimizes the risk of circling pointers which increase the processing time of the entire Tangle.

Figure 4: A new version is appended to the Tangle. Core elements have a primary hash pointer on the direct predecessor (here blue).

iv.2 Tangle Representation in ICN

In order to be able to transfer Tangles in the network, an explanation of representing Tangles in ICNs follows. Instead of representing an entire Tangle as an application data unit in an ICN, each element of a Tangle is represented as a NDO. It allows to fetch/synchronize parts of a Tangle instead of requesting for the entire one.

As mentioned in Section IV.1, a Tangle is given as a list of individual blocks, while each block contains at least two pointers to previous blocks in the structure – the primary and secondary pointers. The following listing illustrates the structure of a Tangle element in TCN:

{
    type: <core, acknowledgement>
    chunkname: <name>,
    primaryhash: <hash>,
    secondaryhash: <hash>,
    
    signature: <signature_of_origin>
}

When creating an acknowledgement element, there is no primary hash to be defined as the element represent meta-information.

Each element of a Tangle is transferred in the network as individual NDO and accessible in the underlying ICN using a content identifier. In TCN, we propose the following naming structure to access an element of a Tangle:

    <NDO-Tangle-name>/<hash-value>/<version-number>

The structure allows to provide fine-grained access to a Tangle element, e.g., to a particular version. The name of the actual chunk can be chosen according to the permitted name space.

Each time, a new element is added to the Tangle, a new version is created and appended as the tip. As tips always represent the starting point for synchronizing a Tangle, the proposed naming convention to access the tip of a Tangle is:

    <NDO-name>/<version-number>.

In order to ensure to receive the latest version from the origin, a consumer node has to specify a cache bypass signal as part of the request (e.g., ”must-be-fresh” flag in NDN).

V TCN - Synchronization of Tangles

The synchronization of Tangles and their contents across multiple consuming nodes in the network describes a major aspect in TCN. For example, if a new version of a NDO is created, both the Tangle and its elements as well as the consuming nodes have to be updated to the latest version. However, as a Tangle represents a data structure distributed across the network, it describes a non-trivial task to update records as well as to update forwarding rules to reach the latest version.

v.1 Bootstrapping and Synchronization

The synchronization is separated into two parts: (i) bootstrapping – the initial Tangle information are requested, and (ii) synchronization – partial or full synchronization of a Tangle with other nodes.

v.1.1 Bootstrapping

The Tangle tips are ideal to bootstrap a Tangle as they represent the elements without incoming edges. By querying the network for the desired NDO using its content identifier, a consuming node will receive the tip of the Tangle (cf. Section IV.2). Starting from the tips, the node will traverse the Tangle to the first block, requesting for all predecessor elements as well as all chunks of the desired NDO using the (primary) hash pointers provided in each element. While traversing backwards through the Tangle, a node can already fetch the latest versions of chunks. By evaluating the acknowledgements of the Tangle, the node can decide to fetch further elements of the Tangle, or to drop these parts. The node will proceed the initial bootstrapping as long as all elements are received.

v.1.2 Synchronization

In order to get updates on the Tangle, the node will setup a synchronization of the tips. This can happen either by frequently poll for new versions, or using an ICN synchronization protocol such as PSync Zhang et al. (2017) or ChronoSync Zhu and Afanasyev (2013). Thereby, TCN benefits from the ICN in-network caching capability for which the network will automatically store replicas frequently in forwarders to increase the availability of data in case of node failures. In case a new element is appended to a synchronized Tangle, either a new entry is added to the list of tips or it will be linked to a synchronized tip. As a result, any updates can be quickly identified and the Tangle is synchronized accordingly. It has to be mentioned that the synchronization interval to be selected for a Tangle is dependent on the application type. The frequent data is generated or requested by the application, the shorter synchronization intervals are required.

v.1.3 Logical Tangle Representation for Special Interactions

Special types of application interaction patterns, e.g., streaming of data such as video, are challenging to be realized as Tangles as the pure structure only allows traversing backwards. To overcome this limitation, a node has to create a logical representation of the Tangle in the reverse order the Tangle is traversed from the tips to the start. When a node starts synchronizing a Tangle, it will store the elements in the MST in reversed order as traversed from the tips to the start. The logical representation allows to identify and request for the ’next’ elements of the NDO to be streamed.

v.2 Synchronization Chain - Update Forwarding Rules

The synchronization of a Tangle across the network requires full interconnection of subscribing nodes as potentially each participating node can add new blocks to the Tangle. This situation challenges the synchronization procedure in TCN as several updates might be received in a converging node. To overcome this limitation, TCN establishes a logical synchronization chain between participating nodes.

After a consumer bootstrapped a Tangle, it will send out a special notification message into the network to discover at least one other node synchronizing on the same Tangle, e.g., using the postfix findsyncpartner in the content identifier.

    <Tangle-name>/<nonce>/findsyncpartner

If the notification message is overheard by a potential synchronization partner, the partner will respond back to the notification. This response message is processed differently by the TCN forwarding pipeline by updating entries in the forwarding table to establish a bidirectional connectivity between these nodes. As a result, request and response messages for the particular Tangle on the network interfaces are forwarded towards the synchronization partners.

To establish a bidirectional connectivity, we propose a three way handshake (cf. Figure 5), so the new created FIB entries will only be persistent, if the initializing node confirms to the new routes. All forwarding entries created by TCN are time-limited to avoid security threats such as Denial-of-Service attacks. A heartbeat mechanism ensures that, in case of a timeout, FIB entries are removed accordingly.

Figure 5: Scheme of the synchronization chain handshake procedure. First sending an interest to all matching FIB entries, next receiving a NDO to set time-limited forwarding rules, last completing the synchronization handshake and starting the heartbeat message procedure.

After the synchronization routes are established successfully, the nodes can start to synchronize on the Tangle tips. In case a Tangle contains multiple tips received by a node, it has to merge the tips by eliminating duplicated entries in the list of tips.

In case a connection loss happened and the disconnected node extends the Tangle with new elements (e.g., the vehicle drives into a tunnel having no connection to the communication infrastructure), it will restart the bootstrapping of the Tangle after re-connecting to the network. Other synchronization partners will receive the changes and decide whether to accept or reject to the latest changes using acknowledgements.

Vi Evaluation

In order to evaluate the scalability of TCN, the networking simulator NS-3 Henderson et al. (2018) and the NDN specific protocol stack bundle ndnSIM 2.7 Mastorakis et al. (2017) are used to create the simulation. Dependent on the number of synchronization nodes, the time required to synchronize to parts as well as a full Tangle is compared against the FLIC Manifest proposal.

vi.1 Synchronization

As topology for our simulation we use the rocket-fuel typology Spring et al. (2002)111more specific the 1221.cch based on https://github.com/cawka/ndnSIM-sample-topologies including 2766 nodes with a bandwidth capacity between MBps and MBps, representing a hierarchical network as shown in Figure 6. We run the evaluation times and every time we initialized the bandwidth capacity of the links differently.

Figure 6: Rocketfuel Topology with 2766 nodes, visualized with pyviz in ndnSIM.

To evaluate the scalability of TCN, we choose randomly nodes (range: up to ) to be involved in the procedure. The size of the NDO to be modeled as a Tangle is GB, while each chunk is of size KB. Based on these parameters, the Tangle to be simulated consists max. of blocks. In the Tangle bootstrapping, all nodes synchronize the content of the Tangle. Afterwards, nodes will start to append new chunks of max. size MB to the Tangle (max. additional blocks in total). We measure the time taken to synchronize the entire Tangle at every participating node. Moreover, we request the actual data and measure the time until all nodes have fully synchronized to the desired data. The bandwidth is randomly chosen per link, between MBps and MBps.

We simulate the scenario either using FLIC and a full-synchronization of a Tangle. The results are illustrated in Figure 7. It can be seen that FLIC requests the entire Manifest again when a change happend in the NDO. When looking at the synchronization time, it can be seen that TCN has a rather constant time saving compared to full synchronization in FLIC.

Figure 7: Result of full synchronization using TCN and FLIC (100 runs with random bandwidth initialization).

This is due to the fact that a fewer number of Manifest packets have to be transferred in the network as we append elements to the Tangle, while FLIC requires a re-creation of the entrie Manifest structure. The experiment shows, that an efficient Manifest structure can help to speed up real world applications. The synchronization time has a roughly linear grow despite the number of nodes is exponential growing. This can be explained by the intrinsic multicast and in-network caching capabilities of NDN as forwarding nodes in the simulated topology will respond to synchronization requests with cached data.

In a second experiment we use the same setting, but we want to analyze the scaling behavior of TCN vs FLIC. Therefore, we change the size of the initial data to , , , , , , , , , , and MB and we observe the time how long TCN and FLIC need to synchronize additional MB. The result is shown in Figure 8.

Figure 8: Result of full synchronization using TCN and FLIC with different file sizes.

We see that for small data (, , MB) TCN and FLIC have a rather similar performance. However, with increasing file sizes, full synchronization with FLIC as manifest becomes slower than TCN due to the overhead of requesting the entire manifest compared to TCN only fetching the new blocks. Thus, we find that with increasing file size TCN scales very well. This is important, since when the amount of synchronized data grows, the synchronization overhead should not increase for optimal performance.

Vii Discussion

In IOTA, Tangles offer a lightweight solution to handle data of IoT scenarios in a distributed manner, while not relying on concepts such as proof-of-work or a transaction fee as Blockchain. By providing additional features such as consensus between partner nodes as well its conceptual fit to the proposed structure of Manifests as in FLIC Tschudin and Wood (2016), TCN overcomes the limitations of tight name-to-data coupling. These properties makes TCN an interesting candidate for distributed applications deployed especially in edge computing environments. However, there are additional aspects of TCN not addressed so far.

vii.1 TCN – Security & Trust

The current design of TCN allows easy participation of nodes on the Tangle structure. Every node which is able to synchronize a Tangle is able to append data to it, even malicious one, due to a missing concept for authorization. However, similar as in Blockchains, Tangles establish a trust model based on consensus. Data will only be synchronized if an element is acknowledge by subsequent elements. Elements which get significantly less acknowledgements will be dropped from the Tangle after some time (Tangle convergence), while verified elements remain in the Tangle.

As in ICN every node is required to sign a content packet, signatures within the packets might be used to authenticate a node against a Tangle. Additional mechanisms to handle permissions to operate on the Tangle can help to prevent a node publishing malicious data.

vii.2 TCN – Intelligent Cache Management

The information modeled within a Tangle can be used for cache decision making. A node synchronizing a Tangle can anticipate the next data chunk to be requested by a consumer node, pre-fetching and storing it within its local cache pro-actively. As a result, TCN forwarding nodes turn into data repositories. Such feature might be useful in time-sensitive use case scenarios such as connected vehicles Scherb et al. (2019a). For example, proactively storing data at edge nodes, e.g., traffic information about a hazardous situation ahead, improves data dissemination in mobile scenarios. Furthermore, as Tangles allow to append data to an existing structure, vehicles can append own generated data or even carry data to areas not covered by a communication infrastructure, and thus, contribute to improve the quality of the distributed application.

vii.3 TCN – Flexible Name-to-Data Binding

ICNs tightly couple content identifier and actual data. The mandatory signing procedure of ICNs ensures that these bindings can be verified at client side (or even forwarder) by relying on a Public Key Infrastructure (PKI). New or updated content has to be published using a new identifier. Especially, Manifest solutions like FLIC require to re-create its entire structure in case of any changes. TCN revises the tight coupling as Tangles allow to extend the existing structure by adding new content to the Tangle on demand. The acknowledgement mechanism of Tangles helps to establish consensus on valid elements, while less valid content will be evicted from the Tangle from time to time. As a result, data can be enhanced not only by the originator of the data which is essentially different compared to plain NDN solutions. To this end, TCN moves management complexity from the application level into the Tangles enabling the support of cooperative application.

vii.4 TCN – Towards Compute-Centric Architectures

The introduction of TCN have shown improvements via network level consensus and efficient management of data chunks (cf. Section VI). However, the concepts of Tangles are promising for compute-centric architectures such as Named Function Networking (NFN) Sifalakis et al. (2014), named function as a service (NFaaS) Król and Psaras (2017), or Compute First Networking (CFN) Król et al. (2019) as well. For example, the electronic horizon application logic can be modeled as a compute graph using Tangles. By doing so, the Tangle can be synchronized between execution nodes to coordinate the execution of computations across cloud and edge environments, and thus, ensure to fulfill application demands. Further application domains which might benefit from such concept include distributed database systems, or distributed chat applications like Scuttlebutt Tarr et al. (2019); Scherb et al. (2021). We briefly discuss the potentials of the future work on Tangle Function Networking (TFN) – an extension of TCN supporting the coordination of computation state across multiple execution nodes in a distributed and transparent fashion.

vii.4.1 Tangle Function Networking

NDN has been proven by several applications to be a good basis for network computing. NFN Sifalakis et al. (2014); Scherb et al. (2016), NFaaS Król and Psaras (2017), CFN Król et al. (2019), etc are examples for network computing frameworks for NDN. When looking into the concepts of NFN and NFaaS, it can be seen that both support the execution of stateless functions as in the ”function-as-a-service” paradigm. Besides stateless functions, CFN supports the execution of stateful Actors by synchronizing compute state using CRDTs. Instead of using CRDTs, Tangles can be used for the following reasons: (i) allow for collaborative resolution of execution nodes, and (ii) allow to dynamically extend the graph by other nodes during runtime (e.g., to store and synchronize local variables and intermediate results).

A Tangle in TFN consists of two blocks: functions, and data (input, compute state or compute result), therefore, supports both stateless functions and stateful computations (cf. Figure 9

). Each of these blocks are represented as individual elements in the Tangle. When an execution node parses the Tangle, it can decide to execute a function of the graph. Pointers to additional information such as the location of the function executable, as well as further data is available in the Tangle as well. In case a compute result is available, the Tangle is updated accordingly that subsequent execution nodes can query quickly the network for the result. Furthermore, modeling a compute graph using Tangles allows for parallel processing of the entire graph. In case multiple execution nodes are involved in the overall computation, a node takes over responsibility to execute a function by acknowledging the execution in the Tangle, and synchronized partners will be notified accordingly. Furthermore, it limits the probability that a function within the Tangle is executed in parallel by different nodes.

As we move toward a distributed edge computing environment, the concept of TCN is promising for compute-centric networking architectures Scherb and Tschudin (2018); Scherb et al. (2019b). It allows the compute network to change or extend computation graphs during the runtime, bringing more flexibility than all other computation frameworks introduced so far Scherb et al. (2017). For example in the electronic horizon scenario (cf. Section II), to warn the driver about a hazardous situation on the junction ahead, nodes can append image processing computations of a camera deployed close to the junctions to the compute Tangle or append the processing result to the Tangle as additional input for the computation Scherb et al. (2018); Grewe et al. (2018). Another promising feature, especially in mobile scenarios is the capability that Tangle-based computations can be continued offline in case of connection loss.

Figure 9: Compute Graph of the function call func1(func2(data3),data1) in TFN. This figure shows only logical compute graph excluding the second hash reference of the tangle.

Viii Conclusion

In this paper, we present the challenge of tight name-to-data binding in ICNs, especially for scenarios in which Manifest solutions are used. To address the limitations of the tight coupling, we present Tangle Centric Networking, a network level consensus and synchronisation extensions for ICNs. In TCN, the Manifest of each NDO is represented as a Tangle, that enables the network to add or update content across multiple consumers in a distributed fashion.

We implemented the concept of TCN in simulation and compared it against the ICN Manifest solution FLIC. The results show that Tangles provides an efficient way to synchronize immutable and mutable state over the network, while the additional synchronization overhead is negotiable when popular large files frequently change in the network. Therefore, TCN and its Tangle concept improves the performance of data retrieval for these types of data in an ICN.

As we move toward a distributed edge computing environment, we discuss the concept of TCN as a promising extension to manage compute-centric networking architectures more efficiently. Future work of TCN has to address the presented open directions, especially these points regarding security and trust management.

References

  • A. Afanasyev, X. Jiang, Y. Yu, J. Tan, Y. Xia, A. Mankin, and L. Zhang (2017) NDNS: a dns-like name service for ndn. In 2017 26th International Conference on Computer Communication and Networks (ICCCN), pp. 1–9. Cited by: §I, §III.1.
  • M. Amadeo, C. Campolo, J. Quevedo, D. Corujo, A. Molinaro, A. Iera, R. L. Aguiar, and A. V. Vasilakos (2016) Information-centric networking for the internet of things: challenges and opportunities. IEEE Network 30 (2), pp. 92–100. External Links: Document Cited by: §I, §III.1.
  • L. Andreone, R. Brignolo, S. Damiani, F. Sommariva, G. Vivo, and S. Marco (2010) Safespot final report. technical report d8.1.1. Technical report Note: Accessed on: May 06th, 2021 External Links: Link Cited by: §II.1.
  • F. Bonomi, R. Milito, J. Zhu, and S. Addepalli (2012) Fog computing and its role in the internet of things. In Proceedings of the First Edition of the MCC Workshop on Mobile Cloud Computing, MCC ’12, New York, NY, USA, pp. 13–16. External Links: ISBN 9781450315197, Link, Document Cited by: §I.
  • R. Buyya and A. V. Dastjerdi (2016) Internet of things: principles and paradigms. Elsevier. Cited by: §II.
  • dSPACE GmbH (2010) External Links: Link Cited by: §II.1.
  • European Telecommunications Standards Institute (2021)

    ETSI Open Source MANO

    .
    Note: (Accessded on) April 28, 2021 External Links: Link Cited by: §I.
  • Forbes (2021) Internet of Things (IoT) connected devices installed base worldwide from 2015 to 2025 (in billions). Note: Statista Inc., (Accessded on) January 25, 2021 External Links: Link Cited by: §I.
  • E. Foundation (2021) External Links: Link Cited by: §III.2.
  • S. Gilbert and N. Lynch (2002) Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News 33 (2), pp. 51–59. External Links: ISSN 0163-5700, Link, Document Cited by: §III.2.
  • R. B. GmbH (2020) External Links: Link Cited by: §II.1.
  • D. Grewe, C. Marxer, C. Scherb, M. Wagner, and C. Tschudin (2018) A network stack for computation-centric vehicular networking. In Proceedings of the 5th ACM Conference on Information-Centric Networking, pp. 208–209. Cited by: §VII.4.1.
  • D. Grewe, M. Wagner, M. Arumaithurai, I. Psaras, and D. Kutscher (2017) Information-centric mobile edge computing for connected vehicle environments: challenges and research directions. In Proceedings of the Workshop on Mobile Edge Communications, pp. 7–12. Cited by: §II.1, §III.1.
  • T. Henderson, M. Lacage, G. Riley, M. Watrous, G. Carneiro, and T. Pecorella (2018) External Links: Link Cited by: §VI.
  • IOTA Foundation (2020) External Links: Link Cited by: §I, §III.2.
  • V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, and R. L. Braynard (2009) Networking named content. In Proceedings of the 5th international conference on Emerging networking experiments and technologies, pp. 1–12. Cited by: §I, §III.1.
  • M. Król, S. Mastorakis, D. Oran, and D. Kutscher (2019) Compute first networking: distributed computing meets icn. In Proceedings of the 6th ACM Conference on Information-Centric Networking, pp. 67–77. Cited by: §III.2, §VII.4.1, §VII.4.
  • M. Król and I. Psaras (2017) NFaaS: named function as a service. In Proceedings of the 4th ACM Conference on Information-Centric Networking, pp. 134–144. Cited by: §VII.4.1, §VII.4.
  • S. Mastorakis, A. Afanasyev, and L. Zhang (2017) On the evolution of ndnSIM: an open-source simulator for NDN experimentation. ACM Computer Communication Review. Cited by: §VI.
  • Michał Król and Ioannis Psaras (2018) SPOC: secure payments for outsourced computations. External Links: 1807.06462 Cited by: §III.2.
  • H. Moustafa, E. M. Schooler, and J. McCarthy (2017) Reverse cdn in fog computing: the lifecycle of video data in connected and autonomous vehicles. In 2017 IEEE Fog World Congress (FWC), Vol. , pp. 1–5. External Links: Document Cited by: §I, §II.1, §II.1.
  • S. Nakamoto (2019) Bitcoin: a peer-to-peer electronic cash system. Technical report Manubot. Cited by: §III.2.
  • S. Popov (2018) The tangle. White paper 1, pp. 3. Cited by: §I, §III.2, §IV.
  • C. Scherb, P. Bürklin, and C. Tschudin (2021) SCoIoT: swarm-computations for the internet of things. In IEEE ICCCN 2021, Vol. , pp. . External Links: Document Cited by: §VII.4.
  • C. Scherb, S. Emde, C. Marxer, and C. Tschudin (2019a) Data upload in mobile edge computing over icn. In 2019 IEEE Globecom Workshops (GC Wkshps), pp. 1–6. Cited by: §VII.2.
  • C. Scherb, B. Faludi, and C. Tschudin (2017) Execution state management in named function networking. In 16th International IFIP TC6 Networking Conference, Networking 2017, Cited by: §VII.4.1.
  • C. Scherb, D. Grewe, M. Wagner, and C. Tschudin (2018) Resolution strategies for networking the iot at the edge via named functions. In Consumer Communications & Networking Conference (CCNC), 2018 15th IEEE Annual, Vol. 15. Cited by: §VII.4.1.
  • C. Scherb, C. Marxer, and C. Tschudin (2019b) Execution plans for serverless computing in information centric networking. In Proceedings of the 1st ACM CoNEXT Workshop on Emerging in-Network Computing Paradigms, pp. 34–40. Cited by: §VII.4.1.
  • C. Scherb, M. Sifalakis, and C. Tschudin (2016) A packet rewriting core for information centric networking. In 2016 13th IEEE Annual Consumer Communications & Networking Conference (CCNC), pp. 67–72. Cited by: §VII.4.1.
  • C. Scherb and C. Tschudin (2018) Smart execution strategy selection for multi tier execution in named function networking. In IEEE ICC 2018, Cited by: §VII.4.1.
  • W. Shang, Y. Yu, L. Wang, A. Afanasyev, and L. Zhang (2017) A survey of distributed dataset synchronization in named data networking. Technical report University of California, Los Angeles. Note: NDN Technical Report NDN-0053 Cited by: §III.1.
  • M. Shapiro, N. Preguiça, C. Baquero, and M. Zawirski (2011) Conflict-free replicated data types. In Stabilization, Safety, and Security of Distributed Systems, Berlin, Heidelberg, pp. 386–400. External Links: ISBN 978-3-642-24550-3 Cited by: §I, §III.2.
  • M. Sifalakis, B. Kohler, C. Scherb, and C. Tschudin (2014) An information centric network for computing the distribution of computations. In Proceedings of the 1st international conference on Information-centric networking, pp. 137–146. Cited by: §VII.4.1, §VII.4.
  • N. Spring, R. Mahajan, and D. Wetherall (2002) Measuring isp topologies with rocketfuel. ACM SIGCOMM Computer Communication Review 32 (4), pp. 133–145. Cited by: §VI.1.
  • M. Swan (2015) Blockchain: blueprint for a new economy. ” O’Reilly Media, Inc.”. Cited by: §III.2, §IV.1.
  • D. Tarr, E. Lavoie, A. Meyer, and C. Tschudin (2019) Secure scuttlebutt: an identity-centric protocol for subjective and decentralized applications. In Proceedings of the 6th ACM Conference on Information-Centric Networking, pp. 1–11. Cited by: §VII.4.
  • C. Tschudin and C. Wood (2016) File-like icn collection (flic). Internet Engineering Task Force, Internet-Draft draft-tschudin-icnrg-flic-00. Cited by: §I, §I, §III.1, §IV.1.2, §IV, §VII.
  • J. Wang, J. Liu, and N. Kato (2019) Networking and communications in autonomous driving: a survey. IEEE Communications Surveys Tutorials 21 (2), pp. 1243–1274. Cited by: §II.1.
  • L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, K. Claffy, P. Crowley, C. Papadopoulos, L. Wang, and B. Zhang (2014) Named data networking. ACM SIGCOMM Computer Communication Review 44 (3), pp. 66–73. Cited by: 2nd item, §III.1, §IV.1.2.
  • M. Zhang, V. Lehman, and L. Wang (2017) Scalable name-based data synchronization for named data networking. In IEEE INFOCOM 2017 - IEEE Conference on Computer Communications, Vol. , pp. 1–9. External Links: Document Cited by: 2nd item, §III.1, §V.1.2.
  • Z. Zhu and A. Afanasyev (2013) Let’s chronosync: decentralized dataset state synchronization in named data networking. In 2013 21st IEEE International Conference on Network Protocols (ICNP), Vol. , pp. 1–10. External Links: Document Cited by: §III.1, §V.1.2.