In-Network Retransmissions in Named Data Networking

The strategy layer is an important architectural component in both Content-Centric Networking (CCN) and Named Data Networking (NDN). This component introduces a new forwarding model that allows an application to configure its namespace with a forwarding strategy. A core mechanism in every forwarding strategy is the decision of whether to retransmit an unsatisfied Interest or to wait for an application retransmission. While some applications request control of all retransmissions, others rely on the assumption that the strategy will retransmit an Interest when it is not satisfied. Although an application can select the forwarding strategy used in the local host, it cannot guarantee the selection of the same strategy in other nodes in the network, especially in shared resource environments. In some scenarios, a developer must bind the implementation of the application to the details of the deployed forwarding strategy to guarantee the correctness of his application. In this paper we discuss the core mechanisms of a forwarding strategy in NDN, and we explore the importance and impact of in-network retransmissions on the application\u27s performance and correctness. We propose and implement a simple forwarding strategy abstraction that allows the application to decide whether a network retransmission is required, and differentiate application retransmissions from network retransmissions. We show that in some scenarios, such as multiple producers application or multipath consumer-producer service, the proposed abstraction can significantly reduce the percentage of unsatisfied Interests

Decoupling Information and Connectivity via Information-Centric Transport

The power of Information-Centric Networking (ICN) architectures lies in their abstraction for communication --- the request for named data. This abstraction promises that applications can choose to operate only in the information plane, agnostic to the mechanisms implemented in the connectivity plane. However, despite this powerful promise, the information and connectivity planes are presently coupled in today\u27s incarnations of leading ICNs by a core architectural component, the forwarding strategy. Presently, this component is not sustainable: it implements both the information and connectivity mechanisms without specifying who should choose a forwarding strategy --- an application developer or the network operator. In practice, application developers can specify a strategy only if they understand connectivity details, while network operators can assign strategies only if they understand application expectations. In this paper, we define the role of forwarding strategies, and we introduce Information-Centric Transport (ICT) as an abstraction for cleanly decoupling the information plane from the connectivity plane. We discuss how ICTs allow applications to operate in the information plane, concerned only with namespaces and trust identities, leaving network node operators free to deploy whatever strategy mechanisms make sense for the connectivity that they manage. To illustrate the ICT concept, we demonstrate ICT-Sync and ICT-Notify. We show how these ICTs 1) enable applications to operate regardless of connectivity details, 2) are designed to satisfy a predefined set of application requirements and are free from application-specifics, and 3) can be deployed by network operators where needed, without requiring any change to the application logic

Decoupling Information and Connectivity via Information-Centric Transport

The power of Information-Centric Networking architectures (ICNs) lies in their abstraction for communication --- the request for named data. This abstraction was popularized by the HyperText Transfer Protocol (HTTP) as an application-layer abstraction, and was extended by ICNs to also serve as their network-layer abstraction. In recent years, network mechanisms for ICNs, such as scalable name-based forwarding, named-data routing and in-network caching, have been widely explored and researched. However, to the best of our knowledge, the impact of this network abstraction on ICN applications has not been explored or well understood. The motivation of this dissertation is to address this research gap. Presumably, shifting from the IP\u27s channel abstraction, in which two endpoints must establish a channel to communicate, to the request for named data abstraction in ICNs, should simplify application mechanisms. This is not only because those mechanisms are no longer required to translate named-based requests to addresses of endpoints, but mainly because application mechanisms are no longer coupled with the connectivity characteristics of the channel. Hence, applications do not need to worry if there is a synchronous end-to-end path between two endpoints, or if a device along the path switches between concurrent interfaces for communication. Therefore, ICN architectures present a new and powerful promise to applications --- the freedom to stay in the information plane decoupled from connectivity. This dissertation shows that despite this powerful promise, the information and connectivity planes are presently coupled in today\u27s incarnations of leading ICNs by a core architectural component, the forwarding strategy. Therefore, this dissertation defines the role of forwarding strategies, and it introduces Information-Centric Transport (ICT) as a new architectural component that application developers can rely on if they want their application to be decoupled from connectivity. When discussing the role of ICT, we explain the importance of in-network transport mechanisms in ICNs, and we explore how those mechanisms can be scalable when generalized to provide broadly-applicable application needs. To illustrate our contribution concretely, we present three group communication abstractions that can evolve into ICTs: 1) Data synchronization of named data. This abstraction supports applications that want to maintain data consistency over time of a group\u27s shared dataset. 2) Push-like notifications for the latest named data. This abstraction supports applications that want to quickly notify and be notified about the latest content that was produced by a member(s) in the group. And 3) distributed named data fetching when the content is partitioned. This abstraction supports applications that their named data is partitioned and distributed in the group, and the names of content items in a partition cannot be generalized and hierarchically represented using one partition name. For each ICT, we provide examples of known applications that can use it, we discuss different mechanisms for implementation, and we evaluate selected implementations. We show how by relying on an ICT instead of a forwarding strategy, the tested applications can maintain sustainable communication in connectivities where IP tools fail or do not work well