d4.1: 1st yearly wp4 report & demonstration - gwdg · vpp vector packet processing cicn...

D4.1: 1st Yearly WP4 Report &Demonstration

Project acronym:

Project title: ICN2020: Advancing ICN towards real-world deployment through research,innovative applications, and globalscale experimentation

Grant Agreement number: 723014, NICT-184

Funding Scheme: Horizon 2020

Deliverable Type Report

Dissemination Level PU

Contractual date ofDelivery:

30 June 2017

Actual date of delivery: 04 August 2017

Project duration: 36 months

Work package: WP 4: Testbeds and Experiments

Lead Editor: Angelo Mantellini and Jun-ichi Yam-aguchi

Editors: Jacopo De Benedetto, Sripriya Ad-hatarao, Mayutan Arumaithurai

Contributors: ALL

Reviewed By: Mayutan Arumaithurai, Sripriya Ad-hatarao

ICN2020 D4.1: 1st Yearly WP4 Report & Demonstration Internal Report Month 12 1 of 51

Abstract: As the first-year deliverable of WP4, we focus ontasks related to ICN testbeds. The deliverable reports the workdone on the deployment, configuration and use of ICN testbeds.This work package is composed of two tasks dedicated to localand federated testbed scenarios, and one task dedicated to therelated experiments. In this deliverable we list the contributionsfor the Y1 of the ICN2020 project.


Executive SummaryThis deliverable depicts our effort in the first year to establish global-

scale ICN testbeds. The goal is to enable a common environment tohost ICN experiments, with special attention to large deployments.

Global-scale experiments are the fundamental metrics to prove thebenefits of ICN communication paradigm, but require proper testbedsto be executed. A general, non-simulated and easy to manage testingenvironment is still missing, with the exception of few proposals thatare mostly bounded to a particular ICN implementation or to specificuse-case scenarios. Together with appropriate experiments, new andexisting tools will be analyzed to ease the creation of general-purposeICN testbed or to extend functionalities of the existing ones.

This work package is composed of three tasks. The first task is re-lated to local testbed environments. Two local testbeds solutions areproposed, located in Japan (JP) and Europe (EU) due to their physicallocation, focusing on IoT testing environments and emulation facilities.In particular, for the EU testbed, the experience in deploying an emulat-ed testbed using tools and services from the CICN project is reported.

The second task is responsible to explore the use and feasibility offederated testbeds. The first contribution is a novel framework, calledCUTEi, to build unified testbeds for ICN that use linux containers toshare the testbed’s hardware resources among different users. In Y1, thedeployment of a first CUTEi testbed is shown with some basic evalua-tions. Then the experience with the NDN testbed is reported and at thesame time some of its limitations are shown. As a solution to the iden-tified limitations, the use of GEANT Testbed Service (GTS) is proposedto both create an independent and isolated global-scale ICN testbed orto extend the functionalities of existing testbeds (e.g.: NDN testbed).

The third task is designed to provide experiments within the proposedtestbeds. In the Y1, we have mainly accumulated experience with thetools and platforms mentioned above and executed some early experi-ments based on prototypes developed as part of the ICN2020 project.In particular, the implementation of a congestion feedback mechanismfor NDN is shown and tested on a local CUTEi-based testbed.


Contents

Glossary 5

1 Introduction 6

2 T4.1 Local-Testbed 72.1 EU local testbed . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 CICN project . . . . . . . . . . . . . . . . . . . 72.1.2 Local testbed at UGOE . . . . . . . . . . . . . 8

2.2 JP Local Testbed . . . . . . . . . . . . . . . . . . . . 92.2.1 Local testbed at UOS . . . . . . . . . . . . . . 9

3 T4.2 Federated-Testbed 113.1 CUTEi testbed . . . . . . . . . . . . . . . . . . . . . . 11

3.1.1 About CUTEi . . . . . . . . . . . . . . . . . . 113.1.2 Management tool for CUTEi . . . . . . . . . . 123.1.3 Evaluation at CUTEi . . . . . . . . . . . . . . . 14

3.2 NDN Testbed Integration . . . . . . . . . . . . . . . . 153.2.1 NDN Testbed Introduction . . . . . . . . . . . 163.2.2 NDN Testbed trust schema . . . . . . . . . . . 193.2.3 Link objects . . . . . . . . . . . . . . . . . . . 223.2.4 Federated Testbed: integration with NDN testbed 253.2.5 Standard operations . . . . . . . . . . . . . . . 253.2.6 Namespace problem . . . . . . . . . . . . . . . 263.2.7 Operations guide . . . . . . . . . . . . . . . . . 28

3.3 GTS for ICN testbeds . . . . . . . . . . . . . . . . . . 303.3.1 GTS - GEANT Testbed Service . . . . . . . . . 303.3.2 ICN testbeds on ICN . . . . . . . . . . . . . . . 323.3.3 Demo . . . . . . . . . . . . . . . . . . . . . . . 33

3.4 GTS service for testbeds federation . . . . . . . . . . . 33

4 T4.3 Experiments 354.1 Implementing congestion feedback feature for NDN . . . 35

4.1.1 Congestion feedback in ICN . . . . . . . . . . . 354.1.2 Design of the congestion indicator . . . . . . . . 354.1.3 Evaluation . . . . . . . . . . . . . . . . . . . . 36

4.2 High-speed Software Router . . . . . . . . . . . . . . . 454.3 Experience with testbeds . . . . . . . . . . . . . . . . . 47

5 Ongoing and future activities 49


Glossary

Term Definition

LXC Linux Containers

CCN Content Centric Networking

NDN Named Data Networking

GRE Generic Routing Encapsulation

NFD NDN Forwarding Daemon

MTU Maximum Transmission Unit

PARC Palo Alto Research Center

IRTF Internet Research Task Force

VPP Vector Packet Processing

CICN Community Information-Centric Networking

FIB Forwarding Information Base

NLSR Named Data Link State Routing

RIB Routing Information Base

TLV Type-Length-Value

GTS GEANT Testbed Service

DSL Domain Specific Language

VPN Virtual Private Network

DASH Dynamic Adaptive Streaming over

SDN Software Defined Networks


1 Introduction

This work package is responsible for the creation and development oftestbeds for ICN experiments. The possibility of running global-scaleICN experiments is strictly associated to the availability of proper ICNtestbeds and tools. The main focus of this work-package is to in-vestigate both existing and new solutions to realize ICN testbeds forglobal-scale experiments. In particular, the goal is to create new tool-s or compose existing ones to allow the creation of general-purposeservices not bind to a particular ICN flavor or hardware configuration.These tools will then be used to create or extend ICN testbeds for host-ing experiments based on applications and prototypes proposed in WP2and WP3.

The main objectives of the WP4 includes:

• To deploy local and federated testbeds for experiments in a con-trolled and large scale network environment.

• To run experiments of the developed applications to understandrelations between application and ICN network-layer performances.

• To obtain feedback both from the partners and users by using thedeveloped applications.

• To demonstrate a fully integrated solution that includes: the ICNapplications and services developed in WP2, and the ICN infras-tructure enhancements developed in WP3 on WP4 testbed facili-ties.

The WP4 comprises of three main tasks, the first two are for therealizing the local and federated testbeds respectively and the third taskis for the experiments’ deployments and executions.


2 T4.1 Local-Testbed

The Task 4.1 of WP4 focuses on the deployment of local testbeds tohost applications and prototypes implemented in WP2 and WP3 andthe evaluation of their performance in a controlled and large networkenvironment. The following sections present an overview of the workdone in Y1.

2.1 EU local testbed

In this section we present our experience in deploying a CICN-basedtestbed. We first introduce the CICN project and then report the de-ployment’s experience at the University of Goettingen.

2.1.1 CICN project

The objective of the CICN project is to foster convergence of variousdialects of ICN (CCN and NDN) into a single harmonized version ofICN, promoting wider and faster adoption of ICN-based solutions re-quired to solve future networking needs. Toward this end, Cisco hascreated an open-source project within the FD.IO community in the Lin-ux foundation, called Community ICN (CICN). This project includesCisco’s own ICN software, including the CCN codebase acquired fromPARC. This open-source initiative is intended to accelerate ICN devel-opment by means of community contribution at large and to guaranteecontinued support.

In this project the focus is on the Content-Centric Networking im-plementation (CCNx 1.0) that is under specification in a number ofdocuments of the IRTF ICN research group [1, 2].

The seminal papers describing the CCN architecture [3] report ingreat detail the characteristics of the two systems. Differences amongthe two architectures, especially between CCNx 1.0 and NDN are minorand currently object of a converge effort at the IRTF [4].

The architecture evolution is community driven and the implementa-tion would focus on the harmonization work made by the community asa whole. The project will also provide a number of applications that canbe used by the community to demonstrate the concept as well as runexperiments at scale to evaluate the advantages and benefits of the ICNconcept in concrete use cases like video delivery across 5G networks.

The project scope includes CCN network architecture implementa-tion: packet processing as well as networking socket API. Packet pro-cessing will be made available through two main forwarders one basedon the VPP framework and one based on sockets to deploy CCN in


non VPP environments. While the main focus is on the VPP plugin,the socket based forwarder will be used to enable end-to-end chainstesting, supporting end devices that do not support VPP. Moreover, forthe VPP forwarder, CCNx 1.0 packets will be transported using IPv4encapsulation in the first place. This encapsulation will constitute themain focus for the VPP plugin while the socket-based forwarder couldalso support Ethernet encapsulation as an additional transport example.

Early release of the project target Linux, Android and Apple systems,and include:

1. A VPP forwarder plugin,

2. A socket-based forwarder,

3. The consumer/producer API,

4. A number of support libraries,

5. Examples of CCN applications, including but not limited to an end-to-end example for HTTP ABR video delivery (player and server),

6. Tools suitable to assist with development and testing (vICN).

The reader is invited to refer to the project website at http://

wifi.fd.io/view/Cicn for more information about the project andthe software.

2.1.2 Local testbed at UGOE

A first attempt of a local deployment based on CICN was made at theUniversity of Goettingen. As infrastructural support of the deploymentvirtual machines (VMs) hosted on a XenServer installation (32 vCPU,200GB of RAM) were used.

The deployment is based on VMs manually configured. In this sce-nario, the fact that the CICN project offers, other than the source code,repositories with packages for the major linux distributions (Ubuntu,CentOS), significantly speed up the installation and configuration pro-cess. Nonetheless the manual configuration of each resource representsa great drawback when large and complicated deployments are needed.Again, the CICN project offer another way to create a personalized de-ployment with almost any effort: the project is called vICN is a servicethat takes care of all the configuration needed for an CICN-based deploy-ment. The actual implementation takes advantage of Linux Containers(LXC) to create and manage a virtualized testbed. Using containersinstead of VMs sensibly limits the degradation in the performances dueto ”soft” virtualization and reduce the time needed for creation and


disposal of the instances. In fact, although the deployment was stillbased on VMs allocated on the physical server, the use of Linux Con-tainers on top of them did not show any sign of sensible performancedegradation. As said before, the use of vICN incredibly speed up thedeployment process: after a VM is designed with the orchestrator roleand given a proper configuration file, the script takes care of creatingthe containers and the underlying networking rules. Several parameterscan be passed to the script through the configuration file, such as thetype of forwarder (actually is possible to choose between the socket-based forwarder and the vpp-based forwarder) on a specific node andthe prefixes to be registered on his FIB. It is also possible to choose theimage file to create the containers from, and most importantly you canuse different images for different containers/nodes. The CICN projectprovides an up-to-date pre-configured Ubuntu image to be used, butyou can still use your modified-one (we suggest to always start with theCICN provided image and make changes on top of it to be sure aboutthe compatibility with the script).

We are currently using a CICN testbed of 10 nodes (10 Linux Con-tainers) simulated on a single Virtual Machine. Following the generalrule of assigning at least 1 vCPU and 1 GB of RAM for each nodedeployed, we didn’t face yet any performance issue. At the moment,in such scenario, we tested only the socket-based forwarder, but in thenext future we plan to test also the vpp-based forwarder.

2.2 JP Local Testbed

This section describes a local testbed for IoT experiments deployed atOsaka University (UOS).

2.2.1 Local testbed at UOS

The schematic of the testbed is illustrated in Figure 1. In order to con-duct IoT experiments among partners, a gateway node, which connectsIoT devices to the Internet, have been build at the edge of the testbed.Behind the gateway node, IoT devices that compose the testbed aredeployed at several places in an Osaka University building.

The Intel Joule platform has been selected as the hardware platformfor IoT devices. Some of the IoT devices have been equipped withcameras as sensor devices. We plan to equip the IoT devices with severalkinds of sensor devices, such as thermometers. The gateway node isa server computer having two 16-core CPUs and 128 GB DRAM. Toemulate a large-scale local testbed, the gateway node has several Linux


Sensor Device(Camera)

IoT Devices(Intel Joule)

1000Base-T

IoT Gateway(Server Computer)

The Internet

Osaka University Building

Figure 1: Local testbed deployed at Osaka University

containers (LXD), which are connected to the local testbed and thegateway via Open vSwitch, as shown in Figure 2.

...NFD

COPSS

NFDCOPSS

NFDCOPSS

NFDCOPSS

IoT GatewayOS LXD

eth2(vSwitch)

eth1(Physical)

eth0(Physical)

LXD LXD

The Internet Local Testbed

Figure 2: Configuration of the IoT Gateway Node

NFD has been selected as the underlying ICN forwarding engine.In addition, to support a demonstration of our IoT applications, suchas Publish/Subscribe communication for IoT and emergency servicespresented in D2.1 Sec. 3.1, COPSS has been also installed on thenodes.


3 T4.2 Federated-Testbed

The Task 4.2 of WP4 focuses on the realization of software tools forfederating ICN testbed infrastructures.

The following sections present an overview of the work done in Y1.

3.1 CUTEi testbed

In this section, we describe the CUTEi testbed (Container-based unifiedtestbed for information-centric networking) and its deployment of ourproject.

3.1.1 About CUTEi

CUTEi is a container-based ICN testbed. CUTEi uses linux containertechnology (LXC) to provide multiple isolated user’s spaces at testbedservers. Each user can launch containers at testbed server and evaluateboth ICN-based application and ICN forwarder on containers.

Container-based virtualization (containerization) creates an isolatedlogical space for users with help of the chroot mechanism of operatingsystem, while it does not require the hypervisor and guest OS. Com-pared to the typical virtual machine-based virtualization, containeriza-tion holds three benefits: (i) less overhead, (ii) instant launch of userspace, (iii) easy-to-manage by packaging required libraries.

Containers in the same server run on the same linux kernel, and theycan share the common libraries and softwares. At CUTEi, all requiredcomponents such as libraries and forwarding daemon of CCN are pre-installed and configured in the container. From this functionality, userscan omit the installation operations at every containers. By default,CUTEi container supports one ICN software, CCNx 0.8, and also itequips the specific feature for content cache management of CCNx 0.8that utilizes both memory and linux file system. However, CUTEi doesnot limit the usage of other ICN software, such as NDN. Testbed userscan freely install their own software in their containers.

Users can evaluate both ICN-based application and ICN-forwarder(e.g. performance of routing daemon, caching, strategy) on CUTEitestbed. As stated above, most of the required components for ICNare pre-installed in containers and users can easily evaluate their ICNapplication only by connecting it to the containers. Moreover, privateIP address is allocated to every containers and user can connect andevaluate their own ICN forwarder by installing it in containers (Fig. 3).Detailed network diagram of CUTEi node is shown in Fig.4.


Five organizations from ICN2020 already joined the CUTEi testbed(KDDI, KKE, UOS, OCU, UGOE) and launched their servers. Wedid a preliminary test on the CUTEi for the performance evaluation,installation NFD in containers and verified its connectivity.

Private IP

Common container(lxc0)

Global IP

Usercontainer

(lxc1)

Usercontainer

(lxc2)

Private IP Private IP

KDDI (JP) KKE (JP)

Common container(lxc0)

Global IP

NFDCCNx

Usercontainer

(lxc1)

Figure 3: Example of CUTEi

PhysicalNICeth2

br0

eth0 lxcbr0

veth66

eth0

veth67

eth0

Physical server

CUTEi-VM[kke-n1]

CUTEi-LXC[kke_ndn01]

10.6.47.254 (gw.kke-n1)219.101.148.151 (kke-n1)

219.101.148.149

tun66 tun67gre

CUTEi-LXC[kke_ndn02]

10.6.32.66 (lxc.kke_ndn01) 10.6.32.67 (lxc.kke_ndn02)

FQDN: kke01-cutei.kke.co.jp

FQDN: kke00-cutei.kke.co.jp

eth0eth1eth3

vether pair

Figure 4: CUTEi network diagram

3.1.2 Management tool for CUTEi

At first, we launch our containers on some testbed sites. In CUTEi,website is used for the management of both testbed nodes and con-tainers. Administrators of each testbed site can monitor and control


their testbed servers and containers running on it via website (Fig. 5).Testbed users use website to launch and destroy containers and for re-source reservation at testbed nodes. As shown in the Fig. 6, users cansee the list of CUTEi testbed nodes and launch a container by push-ing create button. From the benefit of containerization, container islaunched within one minute after pushing the ”create” button of web-site. After creating containers, users can get login shell file from thiswebsite and destroy containers only by pushing destroy button.2017/5/22 CUTEi | kddi01

http://133.69.33.148/s/kddi01/home 1/2

kddi01

Summary

Node IP address Last update Containers

kddi01 202.255.44.96 Mon, 22 May 2017 10:41:20 GMT common kddi01_usr kddi01_usr2 kke_u1

kddi01

Resources

Load averages 0.10 0.07 0.06

Free memory 14G

Free VG 187.94G

Containers

common

running

kddi01_usr

cpu 578.6s

memory 1.3GB

network (tx/rx) 414.1MB / 619.4MB

disk (write/read) 1.1GB / 230.7MB

kddi01_dinh

cpu 38.1s

memory 157.8MB

network (tx/rx) 3.4KB / 2.1KB

disk (write/read) 51.2MB / 100.0MB

kke_u1

cpu 1773.9s

memory 272.9MB

network (tx/rx) 218.9KB / 1.5MB

disk (write/read) 291.7MB / 243.6MB

Round Trip Time

id01 2.77ms

id02n1 2.63ms

kansaiu01 10.7ms

kansaiu02 10.5ms

kansaiu03 10.7ms

kansaiu04 10.3ms

keiost01 6.81ms

Figure 5: CUTEi web manager for site administrators2017/5/22 CUTEi | kddi01_ueda | containers

http://133.69.33.148/u/kddi01_ueda/containers 1/1

kddi01_usr | containers

loginid01.sh (/users/kddi01_usr/containers/ id01/login) destroyid01

createid02n1 +

createkansaiu01 +

createkansaiu02 +

createkansaiu03 +

createkansaiu04 +

kddi01 loginkddi01.sh (/users/kddi01_usr/containers/kddi01/login) destroy

keiost01 loginkeiost01.sh (/users/kddi01_usr/containers/keiost01/login) destroy

createkeiost02 +

createkeiost03 +

createkeiost04 +

createkken1 +

kyudai001 [no update]



createnict152 +

createtuat +

createwasedakatto01 +

Figure 6: CUTEi web manager for testbed users


Installation of NFD and our own softwares: Currently, CCNx0.8 is theonly ICN software pre-installed in CUTEi, and we should install NFDmanually. In principle, we can install any software freely, but due to theshortage of allocated memory and storage for each container (Mem-ory:800MB, Storage:2GB), we cannot install NFD from source code.Therefore, it is recommended to install our own software, includingNFD, from binary file. As stated above, containers can share the li-braries and softwares on the host server, thus another option is toinstall NFD in host servers of CUTEi. Although this option requiresthe permission of login to the host server, this option can reduce theper-container installation and users easily create their NFD-enabled con-tainers. We have installed our customized NFD in our testbed serversand add permission for container to use it.

Making NFD topology with external devices: When making NFD topol-ogy, we have to set up NFD routes and connection manually, thereforewe login to the containers for setup. NFDs running on containers areused for the intermediate routers in the topology. After login to thecontainers, the topology was tested by connecting NFDs running onthe containers. CUTEi supports connection from external devices byusing the GRE tunneling.

3.1.3 Evaluation at CUTEi

KDDI KKE

iperf server4@kddi

Usercontainer

Usercontainer

iperf client3@kddi

(Connect via ssh tunnel)tun tun

iperf server2iperf server1iperf client1

NICTUser

containeriperf server3

CUTEi nodes

Local servers

iperf client2

Figure 7: Throughput evaluation on CUTEi


Table 1: Throughput

SRC-DST C1-S2 C1-S3 C2-S3 C3-S1

Throughput 77.0Mbps 77.4Mbps 77.3Mbps 71.2Mbps

SRC-DST C3-S2 C3-S3 C3-S2-S1-S4 C3-S3-S1-S4

Throughput 77.5Mbps 61.8Mbps 64.0Mbps 54.6Mbps

Throughput evaluation We set up a topology shown in Fig. 7 and per-form throughput evaluation using iperf3. All nodes are located in theTokyo prefecture. First, we evaluate internal throughput of testbed,and we use user container at KDDI and KKE as both client and serv-er of iperf3. And as shown in the Tab. 1, each link is stable and itsthroughput is about 77 Mbps. Next, we evaluate the throughput of thetopology that consists of both user containers and external servers. Inthis project, we plan to connect ICN application servers to the CUTEitestbed using gre tunneling, thus this kind of topology can simulate theperformance for this purpose. Client3 and server4 are external devicesthat locate in the kddi-research (Tokyo) and connect to containers withgre tunnel (MTU1476). And we also set two routes from external clientto server, client–kddi–kke–server and client–kddi–nict–server. As shownin the Tab. 1, throughput of external links (C3-S1, C3-S2 C3-S3) variesfrom 62 to 82 Mbps and overall throughput becomes 50 to 60Mbps.

NDN connectivity check with video streaming By using this topology, wealso constructed an NDN network. NFD is installed in the containersand we connect two external NDN servers, video repository and videoplayer, to containers. This video player and repository are the productof this project (Task 2.1). We made a linear array topology shown inFig. 8, and configured a route for video name prefix. As stated above,this route could achieve 64.0 Mbps, and as a natural consequence, weachieved 4.5Mbps video streaming over NDN.

3.2 NDN Testbed Integration

This section depicts our efforts toward allowing the integration of theNDN testbed in a federated one. After an overview of the NDN testbedand its use, we will illustrate some of the potential functionalities wehave identified in order to enable the integration and the relative issues.


KDDI KKEUser

containerUser

container

tun tun

NFDNFDCUTEi nodes

Local servers@kddi

NFD

VLC playerNDN-repo

NFD

$nfdc register /dash/data udp://[ip-kke]

Figure 8: Connectivity test with video streaming

3.2.1 NDN Testbed Introduction

The NDN testbed is a NDN based network created for research purposesthat include software routers application host nodes and other deviceshosted by the institutions participating to the network.

Figure 9 shows the distribution on the node in the various institutionsaround the world.

Figure 9: Distribution of the NDN nodes around the world

The network in composed by 37 nodes that are distributed in threemain areas: USA (see Figure 10(a)), Europe (see Figure 10(b)) andChina/Japan (see Figure 10(c)). Each node is hosted by a participatinginstitution and is identified by an acronym. Each node can be accessedand monitored by a web page that shows the node status. The nodestatus page includes the following information: i) General NFD status;ii) Channels; iii) Faces; iv) FIB; v) RIB; vi) Strategy Choices.


(a) USA part of the NDN testbed

(b) Europe part of the NDN testbed

(c) China and Japan part of the NDN testbed

Figure 10: Main groups of nodes in the NDN network

The overall network status can be monitored by a dedicated pagehosted at Washington University in St. Louis:http://ndndemo.arl.wustl.edu/ndn.html.


Figure 11 reports the network topology with all the 37 nodes, thelink among them and the associated NLSR cost of each link. Moreovera live table reports the status of each node: green nodes have FIB entryfor prefix; red nodes have no FIB entry and yellow nodes have no FIBentry but prefix is in node’s domain.

Figure 11: Topology of the NDN network with the NLSR costs

The testbed status page at the University of Memphis can be ac-cessed using the following link: http://netlab.cs.memphis.edu/script/htm/ndn-status/status.htm.

It reports the NDN routing information retrieved from the Memphisnode. The page reports the advertised prefixes in the network, the


coordinate Link State Advertisement, and the link status.The NDN testbed was or is used from many research projects for ex-

perimenting Real-Time Videoconferencing, Network Management, Se-curity and Privacy and Geo-location of nodes. For example the UCLAteam is implementing real time video conferencing over NDN [5]. TheWashington University is implementing NDN Network monitoring usingNDN [6]. The University of Padua is investigating NDN security withregard to privacy and geolocation [7].

3.2.2 NDN Testbed trust schema

NDN testbed uses an authentication scheme called “trust schema” anddescribed in [8]. Indeed, given that NDN moves data authenticationto the network layer, this implies that every applications must sign andauthenticate every packet. Trust schema is a way to automatize thedecision of who is allowed to sign a given packet. A trust schema iscomposed by a set of linked trust rules and one or more trust anchors.Before describing the NDN testbed trust schema, let we summaries howNDN Data authentication works.

Nodes may request data corresponding to the KeyLocator value,obtaining a public key that in turn is signed, like any other data packet,making it equivalent to a certificate. This procedure is reported inFigure 12. We remark that the data packet whose name is specified bythe KeyLocator name has in turn its own signature section, in which ispresent a KeyLocator field. This allows the creation of a trust chain.

Figure 12: NDN standard authentication

Trust schema defines the schema for the rules of matching betweenthe KeyLocator and the name of the object.

These rules can be applied on both the Interest packets, for instanceto implement access control, and to the Data packet, to implementdata authentication and to block malicious, or in general unauthorized,data producers.


The matching between the key locator and the name on the objectis described in the NFD configuration file nfd.conf through a rule.

A rule defines conditions a valid packet must have and a packet mustsatisfy at least one of the rules defined. Each rule can be broken intotwo parts: matching and checking. A packet is matched against rulesfrom the first to the last until a matched rule is satisfied, otherwise itis considered as invalid. The matching part consists of for section,to match against the packet type (data or interest) and filter sec-tion that describes the conditions on other properties of the packet. Ifthere is a match, packet must pass the checking rule defined in by thechecker section.

The rules are interpreted by an NFD element called Validator, whosedetail are reported here: http://named-data.net/doc/ndn-cxx/0.4.0/tutorials/security-validator-config.html.

With reference to [8] trust schema rules use a notation similar to reg-ular expressions whose syntax is reported in and detailed here: http://named-data.net/doc/ndn-cxx/0.4.0/tutorials/utils-ndn-regex.

html

We obtained the configuration file of a NDN testbed node and weanalyzed the section in which is defined the trust model for NFD RIBManagement.

In what follows we report the first part (”NRD Prefix RegistrationCommand Rule”) of the RIB Management section contained in thenfd.conf configuration file of a node in the NDN testbed.

As we can see, the matching part specify that this rule is for interestpackets that contains the commands of register and unregister

needed to add/remove entries to/from the RIB. The filter regular ex-pression match any packet whose name starts with localhop or local-host, followed by nfd, rib, a component that can either be register orunregister and a final component ”<>” that can be any single namecomponent (wildcard). For these packets, the checking rule states thatan interest must have a ecdsa-sha256 signature and the key locatormust be the certificate name of the signing key expressed in that speci-fied format. If this rule is verified, a new entry in the RIB can be addedor removed.

r u l e{

i d ”NRD P r e f i x R e g i s t r a t i o n Command Rule ”f o r i n t e r e s t

f i l t e r{

t ype name ; c o n d i t i o n on i n t e r e s t name (w/o s i g n a t u r e )r egex ˆ[< l o c a l hop><l o c a l h o s t >]<nfd><r i b>

[< r e g i s t e r ><u n r e g i s t e r >]<>$


}checke r{

t ype cus tomizeds i g−t ype ecdsa−sha256key− l o c a t o r{

t ype namer egex ˆ[ˆ<KEY>]∗<KEY><>∗<ksk−.∗><ID−CERT>$

}}

}

A second rule (omitted for brevity) is identical to this one except forthe signature type section, in which it is specified that also rsa-sha256is accepted.

Given that in NDN also certificates can be fetched as any other datapacket, there are some rules regarding data packets containing a key.

These rules are provided with the name “NDN Testbed HierarchyRule” to filter data corresponding to validate NDN certificates. Thefilter part specify to capture all the identity certificates. Then thechecker is hierarchical that means that it requires that the packetname must be under the namespace of the packet signer.

The final part states that data must have a ecdsa-sha256 signature.Likewise another rule specifies that also rsa-sha256 is allowed.

r u l e{

i d ”NDN Testbed H i e r a r c h y Rule ”f o r dataf i l t e r{

t ype namer egex ˆ[ˆ<KEY>]∗<KEY><>∗<ksk−.∗><ID−CERT><>$

}checke r{

t ype h i e r a r c h i c a ls i g−t ype ecdsa−sha256

}}

The syntax of the rule format is documented in http://named-data.

net/doc/ndn-cxx/0.4.0/tutorials/security-validator-config.

html. In particular, if we look at the default behaviour of the hierar-chical checker, we see that the name components of the KeyLocator

before the token KEY and after KEY but before KSK- must be the prefixof the data name as described in the hierarchical checker rule definitionlisted below:

checke r


{t ype cus tomizeds i g−t ype r sa−sha256key− l o c a t o r{

t ype namehyper−r e l a t i o n{

k−r e g ex ˆ([ˆ<KEY>]∗)<KEY>(<>∗)<ksk−.∗><ID−CERT>$k−expand \\1\\2h−r e l a t i o n i s−p r e f i x −o fp−r e g ex ˆ(<>∗)$p−expand \\1

}}

}

To better clarify how it works, let we make an example. My certifi-cate name is /ndn/guest/KEY/lorenzo.bracciale\%40uniroma2.

it/ksk-1478791848991/ID-CERT/%FD%00%00%01XO%ED%A8%00. TheKeyLocator associated with this name is /ndn/KEY/guest/ksk-1475864051558/ID-CERT 1. The matched part of the components of the KeyLocatorare /ndn/guest. Then, if the certificate name starts with /ndn/guest

the packet is considered as valid, otherwise it is invalid.Finally, the last part of the section defines the trust anchor that is a

pre-trusted certificate. This is a certificate with the role of the root ofcertification chain such as the NDN testbed root certificate.

t r u s t−anchor{

t ype f i l ef i l e −name keys /ndn−t e s tbed−r o o t . ndnce r t . base64

}

3.2.3 Link objects

Link objects are supported by the current NDN forwarding daemon(NFD) allowing to add a greater flexibility in routing interest providedby the introduction of a level of indirection. With link objects, interestcan reach names that are not in the global forwarding table by mappingthem to addresses contained on the table. This concept, called Map-and-Encap, has been used also in several specific designs and has beenproposed for NDN in [9].

A Link object is essentially an association between the name prefix(e.g. /icn2020/video) and the global routed prefixes (e.g. /uniroma2/lbracciale/icn2020/video). Link objects must be authorized by the

1This information can be retrieved through the command ndnsec cert-dump CERT NAME


Figure 13: link objects NDN packet

owner of the original namespace through a signature in order to avoidsecurity issues such as malicious redirection.

For what concern interest packets, interests containing link objectspresent two addition fields in their NDN-TLV as represented in Figure13 where the field “Link” is associated with the link object, and “Se-lectedDelegation” carries the delegation namespace i.e. its index insidethe link object.

Using the python bindings, we can construct an interest with a linkobject with the following code snippet:

from pyndn impor t Namefrom pyndn impor t Facefrom pyndn impor t L inkl = L ink (Name(”/ i cn2020 / v i d eo /LINK”) )l . addDe l ega t i on (10 , Name(”/ uniroma2/ l b r a c c i a l e / i cn2020 / v i d eo ”) )i = I n t e r e s t (Name(”/ i cn2020 / v i d eo ”) )i . s e tL i nkWi r eEncod ing ( l . w i reEncode ( ) )

Link objects are implemented in the current version of NFD. Indeed,if we open the NFD source code file NFD/daemon/fw/strategy.cpp,we see at the LookupFib function (whose interesting part is reportedin Figure 14) how each NFD node forwards interests according to aname if the there is no link object in the packet. Otherwise it routesthe packet according the the contained link objects and the containedSelectDelection field.


Figure 14: Code of the LookupFib function in NFD


3.2.4 Federated Testbed: integration with NDN testbed

In what follow we describe an analysis on the integration with the NDNtestbed platform 2. The motivation behind this research is that we areconsidering NDN testbed as the core network infrastructure of ICN2020federated testbed, around which other edge platforms will be connectedto.

Figure 15: NDN testbed standard operations

3.2.5 Standard operations

To explain the standard operations available in the NDN testbed wepresent an example.

With reference to fig 15 we consider two nodes, one deployed bythe university of Padua (UNIPD), and the other by the WashingtonUniversity in St. Louis (WUSTL). Let we call these “sites”. NDNtestbed is composed by many sites that are forming the NDN testbednetwork, currently composed by 35 nodes whose status is available here:http://ndndemo.arl.wustl.edu/.

Each site is identified by a unique prefix such as /ndn/it/unipd

and /ndn/it/wustl.These site prefixes are distributed on all the nodes of the testbed by

the routing plane as we can see in http://ndndemo.arl.wustl.edu/.Let we consider the case in which we want to connect a consumer to

UNIPD and a producer to WUSTL. We remark that in both cases theconnecting node can be a regular device with an NFD process runningand some software for consuming/producing NDN data. Likewise, we

2https://named-data.net/ndn-testbed/


can also decide to connect to the NDN testbed an NFD gateway, behindwhich we can deploy an entire NFD network.

For simplicity let we consider the simplest case where we have a plainconsumer and a plain producers connected to these two different NDNtestbed nodes.

To connect the consumer, it suffices to insert a face toward the Pad-ua node, while for the producer we need to perform the same operationon the WUSTL node.

However, before connecting to the testbed, we need a certificateissues from some of the site composing the NDN testbed. A semi-automatic procedure exmplained on a dedicated page 3 explain how toobtain such certificate.

It is recommended that the certificate is signed by the site to whichwe want to be connected, so for instance we ask for UNIPD and WUSTLfor two different certificates.

As an example, the certificate name we obtained by WUSTL is /ndn/edu/wustl/\%40GUEST/andrea.detti\%40uniroma2.it. For brevi-ty let we call it CERT NAME. As we can see by the example, CERT NAME

contains the name of the site and we need to install the certificate onthe producer node in order to register prefix on that node.

Then we can use a tool called remote-register-prefix to registerprefix that start with CERT NAME on the node. This operation will triggera FIB update on the FIB node, that we can visualize inspecting thetestbed node FIB on the correspondent page e.g. http://wundngw.

arl.wustl.edu/. We note that remote-register-prefix is notshipped with NFD, but can be cloned using the external git respositoryhttps://github.com/yoursunny/ndn6-tools.

After that we can generate from the consumer an interest packet fora name starting with CERT NAME, e.g. CERT\_NAME/video. Since thispacket has a name that starts with the site prefix /ndn/edu/wustl (asit is contained in the CERT NAME), the packet will transit the testbednodes and eventually arrive to the node where the producer is connectedto. Then, than thanks to the previous FIB update, the interest isforwarder to the producer device.

3.2.6 Namespace problem

Even though the previous procedure allow us to use the testbed, itpresent a severe limitation as it does force us to use a given names-pace. In other words, it does not allow us to produce a contentcalled /icn2020/video and fetch this content from other sites of theNDN testbed. The reason is that the routing plane of the testbed

3https://ndncert.named-data.net/


Figure 16: Solution of the namespace problem using link objects

Figure 17: Java Code for creating an Interest with name delegation

does not propagate the updates of the FIB injected on a node withremote-register-prefix.

A possible solution is to use the so called “Link Objects”. A linkobject is a meta information optionally included in the Interest packetsthat in turn contains Name Delegation. Delegation are essentially othernames, alternative to the Interest Content Name. One link object canhave one or more delegations. Given that NDN is under heavy devel-opment, Link objects are not well documented and we had to resort tothe source code to understand the internals and in particular to analyzethe forwarding procedure in case of Interest containing Link Objects.

Currently link objects are fully supported by NDN and, in turn, bynodes of the NDN testbed.

Every NDN node that processes an Interest, routes first on the del-egation (if present) before routing by the Content Name.

To prevent such operation on the node in charge of delegation weneed to configure NFD by setting in nfd_conf the network region

parameters to make it route by Content Name.


With link objects we can solve the namespace problem by emittingInterest whose Content Name is the name we want on our namespace,and that contains a link object with delegation name pointing to theright CERT NAME. This operation can be easily coded: in Figure 17 wereport a small snippet of Java code implementing this Interest genera-tion.

We tested the solution on the NDN testbed and it worked flawlessly.The overall solution is represented in Figure 16.

We note that what we presented so far are all NDN testbed standardoperations. However we verified that is currently possible to register anarbitrary name on a node FIB (such as /foo) if we have a certificate.

We also verified that the policy of using site dependent certificate toregister a prefix on that site is not enforced: with only one certificatewe can register names on all the sites of the testbed. We do not knowhow long these not-standard features last, anyway to our purpose ofthe presented solution it does not appear critical to loose them.

To summarize, thank to the fact that interest are routed to theLink Objects, we can choose any name we want on the NDN testbed,provided that we know the name of the delegation.

Indeed an open is how a consumer could discover the delegationname given the content name. A possible solution is to use NDNShttps://github.com/named-data/ndns.This option is also consid-ered in [9].

3.2.7 Operations guide

Here we briefly recap the procedure to use an arbitrary naming con-vention on the NDN testbed. In this example we want to publish andretrieve the content identified by the name: ndn:/icn2020/video.We connect the producer to the WUSTL node, and the consumer tothe UNIPD node.

On the producer

1 Get a certificate from https://ndncert.named-data.net/

2 Install the certificate following the instructions included in the e-mail

3 Adjust the network region section in your nfd.conf, by adding forexample /ndn/edu/wustl/\%40GUEST/andrea.detti\%40uniroma2.it

4 re-start your NFD


5 Register a route on a NDN testbed server using the utility remote-register-prefix4,for instance: remote-register-prefix -p /ndn/edu/wustl/

\%40GUEST/andrea.detti\%40uniroma2.it -f tcp4://128.252.153.194:6363

-i /ndn/edu/wustl/\%40GUEST/andrea.detti\%40uniroma2.

it

6 Create a producer application, for instance ndnpingserver ndn:

/icn2020/video

On the consumer

1 Connect to a testbed setting up a face toward that site, for instancenfdc register udp4://ndnnode.math.unipd.it

2 Create and emit an interest with delegation as explained above,using for instance the Java code reported in Figure 17. Thi Interestwill arrive to the NFD of the producer following delegation, thenwill forwarded by content name and in this case will be deliveredto the local application ndnpingserver.

Finally, we noted that once a prefix is registered on a remote n-ode, we can not unregister it and we must wait for the expirationof the FIB entry. This is unconvinient, hence we made a tool calledremoteunregisterprefix to perform such action. We provide thecode of such new utility in the ICN2020 project repository, and we re-port the brief core of the routine hereafter where we use an interestRibUnregisterCommand() for sending a management command tothe NFD node.

voidp r e p a r e C o m m a n d I n t e r e s t ( ){

nfd : : C o n t r o l P a r a m e t e r s params ;params . setName ( m o p t i o n s . p r e f i x ) ;m commandInterest = make shared<I n t e r e s t >(

n fd : : RibUnregisterCommand ( ) . getRequestName (m o p t i o n s . commandPrefix ,params

) ) ;m keyChain . s i g n (∗m commandInterest , m o p t i o n s . s i g n i n g I n f o ) ;m commandInterest−>setTag (

make shared<l p : : NextHopFaceIdTag>( m f a c e I d )) ;

4https://github.com/yoursunny/ndn6-tools


t h i s−>s e t C l i e n t C o n t r o l S t r a t e g y ( ) ;}

3.3 GTS for ICN testbeds

In this section we report our early study on the opportunity to use theGEANT Testbed Service (GTS) as a foundation towards the creation ofa federated ICN testbed. We will first introduce the GTS architectureand functionalities, then illustrate some useful case-scenarios to assesthe benefits that GTS can offer.

3.3.1 GTS - GEANT Testbed Service

The GEANT Testbed Service is an open service made available to net-work research community with the aim to ease the deployment of ex-perimental networks. In particular, the aim of GTS is to address thecommon issue related to network testing facility for a testing environ-ment:

• build at scale;

• spread across different geographical location.

The idea behind GTS is that the networking test facility can be sharedamong users and, through virtualization and isolation of the resources,hosts different experiments. The availability of the resources for theusers is guaranteed by a reservation system and the definition of thetestbed is done with a DSL based on Groovy programming languageand specifically designed to describe a GTS testbed configuration.

The GTS service allows to model a testbed deployment through theDSL using mainly three type of entities:

• Resources represent the basic components to build the testbedand mapped as classes of the DSL;

• Ports represent a resource’s enter and exit points of data flow;

• Adjacencies map the interconnection of the resources using ports.

The current publicly available GTS version (v3.1.1) allows the definitionof 3 type of resources:

• Host resource represents a VM in the network topology. The avail-able parameters of this resource allow to select the geographicallocation (actually nine location are available across Europe), theid (optional), and the ports. The actual version allows only a sin-gle VM flavor (1 vCPU, 4 GB of RAM, 10 GB of storage) and aunique OS image based on Ubuntu 14.04 (64-bit).


Figure 18: GTS modelling and reservation process [from ”1st GTS Workshop - DSLTraining”]

• Link resource represents a virtual link interconnecting two re-sources. Therefore exactly two ports must be provided as param-eters. Other parameters, like the capacity, are available, but theactual version allows only their default value (the default capacityis 10 Mbps).

• OFX resource represents an open flow switch (GTS currently usesHP 5900 Series switches supporting OpenFlow specification 1.3).Other than similar parameters as the Host resource (e.g.: location,ports, etc.), an OFX resource must have one of the ports denotedas the control port of the OpenFlow switch.

• ExternalDomain is a special resource used to describe a resourceoutside the GTS realm (e.g.: a server in an external lab). Theparameters accepted are the location within the GTS availablelocations to be attached to and a port. Unfortunately, the creationof this type of resources needs the manual intervention of a GTSoperator and can’t be automatized.

After the successful registration to the service, a user is assigned to aproject (several users can be assigned to the same project). Each projecthas a fixed amount of resources assigned, and users can create theirown testbed topology using the DSL and reserve the resource needed.If the reservation process succeed, the resources are blocked until thereservation time expires or the reservation is explicitly released. Onlyafter the resources are reserved, it is possible to start the entities thatform the testbed (i.e.: virtual machines and virtual switches). Those


Figure 19: Example of DSL description of a three nodes topology in GTS [from”GTS User Guide v3.1”]

entities can be accessed through a web console on the service webpage,or using a VPN that allows to directly access the internal network ofthe testbed (each project has a unique VPN associated).

The next GTS version (planned for the end of June 2017, but slight-ly delayed) will include some new features like the possibility to choosebetween different VM flavors, upload custom OS images and more im-portantly it will introduce a limited number of BareMetal servers to beused as hosts. For further details on the GTS project and infrastructureplease visit the project homepage:

www.geant.org/Services/Connectivity_and_network/GTS.

3.3.2 ICN testbeds on ICN

In our opinion GTS represents an incredible opportunity to speed-up thedeployment process of ICN experiments and at the same time enableglobal-scale experiments. Until now almost all the ICN experiments areexecuted in simulated environments. The only alternatives for a globalscale experiments is to manage the entire physical deployment or relyon external infrastructures like the NDN Testbed. In the first case, itis necessary not only to consider the cost of hardware equipments thatcan be excessive for a single organization, but also the technical skillsrequired to configure such a distribute deployment, not always possessedby researchers. In such scenario, the use of an existing testbed likethe NDN testbed can be an optimal solution, but still presents somelimitations. In particular, we identified some scenarios where the use ofa global testbed as the NDN testbed presents problems:


• recreate specific network topologies;

• reproduce faults of intermediate nodes (so the ability to selectivelyand temporary ”put offline” a node);

• apply modification to some or all the nodes of the testbed.

The main reason of those limitations derive from the fact that the NDNtestbed hosts don’t allow to logically separate the environment of eachexperiment, and each modification has to first pass the evaluation of thetestbed maintainers before it can be integrated. At the same time, whorun the experiments has no control on the server nodes (maintainedby the on-site operators). In addition, although the modification ofthe nodes is still possible, the process to apply those modificationsinvolves the intervention of the maintainers/operators that often lead todelays in the deployment of the experiments and in the investigation ofpossible bugs. This is why we propose the use of GTS service for createpersonalized testbed deployments where researchers can have completecontrol over the testbed resources and have the possibility to run globalscale experiments in a complete isolated environment. In particular, theisolated environment allows the direct deployment of experiments thatcan potentially beak down the testbed because a potential failure of atestbed will not affect the other testbeds/experiments hosted on thesame infrastructure.

3.3.3 Demo

A demonstration on how to use GTS service to build personalized ICNtestbeds has been developed. The demonstration, other than generalexamples from both NDN and CICN projects, use the SAID prototypedeveloped for WP3 as use-case scenario.Status: The demo is under submission.

3.4 GTS service for testbeds federation

Due to its customizable nature, we envision the GTS service as the per-fect fit to fill the gap between the interconnection of different testbedsand overcome potential issues (See 3.2.4). In particular, we plan touse the ExternalDomain concept to inject portion with modified be-havior within an existing testbed (Fig. 20), or to interconnect differenttestbeds through modified intermediate nodes that can act as gateways.


Figure 20: Example of federated testbed using GTS


4 T4.3 Experiments

The Task 4.3 of WP4 involves the definition and execution of experi-ments to validate applications and ICN functionalities developed in WP2and WP3 over local and/or federated testbeds.

The following sections present an overview of the work done in Y1.

4.1 Implementing congestion feedback feature for NDN

In this section, we describe our implementation of congestion feedbackfeature for NDN.

4.1.1 Congestion feedback in ICN

In ICN, some of the recent researches have used network feedback forcommunication control. Based on these researches, our DASH-basedvideo streaming application utilizes the network feedback feature for rateadaptation. In order to support this kind of application, we implementedthe congestion feedback feature for NFD.

4.1.2 Design of the congestion indicator

In the current internet, congestion causes packet loss due to the in-terface queue overflow at the bottleneck link. Therefore, we regardqueueing delay of egress interface as a congestion indicator. To calcu-late a queueing delay of an egress interface in a linux machine, we usethe libnl3 library to get the interface’s status. Our customized NFDmeasures the current Tx-queue length and calculates the estimatedqueueing delay as a congestion feedback Fcongestion:

Fcongestion = int

(Lqueue

Rpps

× 106)

(1)

Measuring an outgoing link congestion of target router

Producer NDN Router

Consumer

Datareturn

CP

Data

CP

Data

CP

Data

Figure 21: Congestion feedback


Lqueue denotes the length of Tx-queue, Rpps denotes the speed of de-queue (pps), and Fcongestion represents the integer queueing delay in unitof µs. In NFD, a logical Face is used instead of a physical interface.Therefore, in order to calculate and add the congestion feedback, weused the NFD feature to translate the Face into a physical interface.

Implementing congestion feedback in NDN packet NDN data packet isencrypted and/or has the signature for the access control or authen-tication. As a result of this, it is difficult to input information at in-termediate routers. Since the link layer protocol allows modification atintermediate routers, we used the NDNLPv2 header as a container forthe congestion feedback.

4.1.3 Evaluation

In this section, we show the performance evaluation of the congestionfeedback feature.

Evaluation environment In order to confirm the validity of the conges-tion feedback defined in the previous section, we first compared thecongestion and the measured value of the congestion feedback in thetopology where a single router becomes a bottleneck. The measure-ment environment is shown in Figure 22 and Figure 24, where iperfgenerates UDP traffic with no band limit in the background. SRC Aand SRC B in the assumed topology of Figure 22 were replaced withparallel streams (P) from iperf in Node S1 of the measurement system.Nodes S2 and S3 of Figure 24 were installed with the intent of lim-iting the bandwidth of the bottleneck network. The estimator settingfor measuring the transfer speed Rpps was taken as an exponentiallyweighted moving average with a sampling interval of 1 second and in-terval sample number of 4. Based on this, the congestion feedback wasacquired at one second intervals.

Verification of the feedback value At first, we evaluate the feedbackvalue itself. We add background traffic using iperf3, and check thevalue of congestion feedback.

Results of incoming traffic variation The measured result of the rela-tionship between the parallel streams (P) from iperf and the congestionfeedback value Fcongestion when the number of transmission nodes is 1(N=1) in the measurement system of Figure 22 is shown in Figure 23.The transfer speed Rpps shows a constant value of more than 86000


SRC A

SRC B

NDN Router DST

Bottleneck Link

Measurement point

・・・

SRC X

1Gb Ether / Switching HUB

Node S1 Node D

iperf3 –c <Node D> -u -b 0 -P <P >

SRC ASRC BSRC CSRC X …

Measurement point

Figure 22: Measurement Environment 1

20

30

40

50

60

70

80

90

0

1

2

3

4

5

6

7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Avg.

Rpp

s[p

ps]

x 10

00

Avg.

Fco

ngestio

n[m

sec]

Number of Parallel Tx : P

N=1

Avg. FcongestionAvg. Rpps

Inflowing traffic = Congestion indicater

Constant outgoing transfer speed = Link speed

Queue overflow

Figure 23: Results from the Measurement of the Congestion Feedback 1


1Gb Ether / Switching HUB

Node S3 Node S2 Node S1 Node D

<N＝1, 2, 3>

iperf3 –c <Node D> -u -b 0 -P <P=4>

Measurement point

SRC 2

NDN Router DST

Bottleneck Link

Measurement point SRC 3

SRC 1

SWHUB

Figure 24: Measurement Environment 2

20

30

40

50

60

70

80

90

0

1

2

3

4

5

6

7

1 2 3

Avg.

Rpp

s[p

ps]

x 10

00

Avg.

Fco

ngestio

n[m

sec]

Number of Tx Nodes : N

P=4

Avg. Fcongestion

Avg. Rpps

Congestion indicator of outgoing link

Decrease link speed per node

Figure 25: Results from the Measurement of the Congestion Feedback 2


pps irrespective of number of parallel streams (P) from iperf. Fromthis, it can be seen that Rpps directly shows the bandwidth. Increasingthe parallel streams increases the number of queues and this in turncauses the congestion feedback, Fcongestion , to increases in a linearfashion. If the parallel streams (P) exceeds 16, packet dropping occursdue to queue overflow (maximum length of 1000). When the numberof transmission nodes is 1 (N=1), the parallel streams (P) from iperfis equivalent to the multiple data source nodes in the assumed logicaltopology of Figure 22.

Results of outgoing interface congestion When the number of trans-mission nodes (N) is varied and the number of parallel streams is fixed(P = 4) in the measurement system of Figure 24, the respective con-gestion feedback value is shown in Figure 25. Increasing N decreasesthe measured Rpps , thus it can be shown that the congestion feedbackFcongestion increases as the measured transmittable network bandwidthis narrowed.

Validation of the congestion feedback value through RTT measurements

In order to verify that the congestion feedback value is the same as theretention delay time of the actual transmission queue, the congestionfeedback value was compared to the queue delay time calculated fromthe measured RTT value.

Calculation of queue delay time through RTT measurements The mea-surement process is shown in Figure 26 and the tools used for the mea-surement are described in Table 2.

The measurements were carried out according to the following pro-cedures:

(a) Execute all the programs shown in Figure 26 except for iperf3.While there is no traffic from iperf3, take measurements for RTT.Let RTT0 be the average value of RTT in a 60 second time frame.

(b) Run iperf3 and let the iperf3 traffic flow within the network. Bysubtracting RTT0 from each RTT at this time, the retention delaytime of the corresponding UDP packet in the Queue is obtained.(Theoretically, since the network configuration is a full-duplex switch-ing hub, the iperf3 traffic should not be affected by the traffic fromanother host within the hub.)

(c) The congestion feedback value recorded by measure is comparedwith RTT-RTT0 value recorded by rcv.


P=4,8,12

iperf3 -p 5201 -c 10.97.50.30 -u -b 0 -t 70 -P <P>

10.97.50.0/24

GbE

Switching HUB

iperf3

rcv

measure

srv

Queue State Log

iperf3

10.97.50.31 10.97.50.30

10.97.50.29

RTT LogTx

Que

ue

Figure 26: Process for calculating queue delay time using RTT measurements

Table 2: Program tools used for RTT measurements

Program Details

Obtain statistics (QLEN, PPS, BACKLOG, BPS) from Queue for

calculating the congestion feedback every second.

measure After obtaining the required values, the UDP data is immediately

transmitted for RTT measurements with the time of the

transmission being recorded within the UDP payload.

srv Receives the UDP data for RTT measurements and sends

the content back to a specific port of the sender

Receives the UDP data for RTT measurements and calculate RTT

rcv from the current time and the time recorded within the UDP

payload data

iperf3 Generate UDP traffic


Comparison of the congestion feedback value with RTT-RTT0 Thecorrelation between the congestion feedback value and RTT-RT 0 isshown in Figure 27, 28 and 29. From the results, it can be seenthat the RTT-RTT0 value and the congestion feedback value is linearlycorrelated. Moreover, the distribution of delay difference is limited toonly a small area bounded within lines parallel to the linear regressionline This shows that the measured congestion feedback value is able toacquire the queue retention delay time as intended.

y = 0.9663x + 0.593

0.000

0.500

1.000

1.500

2.000

2.500

3.000

3.500

4.000

4.500

0.000 0.500 1.000 1.500 2.000 2.500 3.000 3.500 4.000

RTT

-RTT

0 [

ms]

Congenstion feedback [ms]

P=4

Figure 27: Correlation between congestion feedback value and RTT-RTT0 (P = 4)

Performance overhead of feedback process In this paragraph, the per-formance overhead for the congestion feedback measurement will beevaluated based on its effect on the throughput. Since the congestionfeedback measurement implemented in the previous sections affects thedata transfer performance of the NFD negatively, a method to reducethe performance degradation due to the congestion feedback measure-ment will be proposed here as well.

Overhead Measurement In order to measure the effect of the over-head, the time taken for acquiring a file for the original NFD and theNFD with congestion feedback measurement was recorded and com-pared using repo-ng and ndngetfile. The measurement process is asshown in Figure 30.


y = 0.9884x + 0.5541

0.000

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8.000

0.000 1.000 2.000 3.000 4.000 5.000 6.000 7.000

RTT

-RTT

0 [

ms]


P=8

Figure 28: Correlation between congestion feedback value and RTT-RTT0 (P = 8)

y = 0.9772x + 0.586

0.000

1.000

2.000

3.000

4.000

5.000

6.000

7.000

8.000

9.000

10.000

0.000 2.000 4.000 6.000 8.000 10.000

RTT

-RTT

0 [

ms]


P=12

Figure 29: Correlation between congestion feedback value and RTT-RTT0 (P =12)


10.97.50.0/24

GbE

nfd

repo-ng

nfdnfd

ndngetfile

10.97.50.31

10.97.50.30

10.97.50.29

Figure 30: Congestion feedback overhead measurement process

The size of the file transferred was 1,850,232,832 bytes (about 1.7Gbyte). Since the file was registered in repo-ng with 8 Kbytes/segment,the total number of segments was 225,859 segments. Command:

date; ndngetfile -u -o a.dat /example/data/1/a.dat ; date

Using the command written above, the time difference between the”date” commands were recorded. The settings for the measurementsthat were carried out were as follows:

• Face was set to TCP

• NFD was restarted for each measurement

• No caching by CS

The measurement was carried out 5 times for each configuration andthe results are shown in Table 3. As seen from the 2nd and 3rd columnof Table 3, there is a significant degradation in performance betweenthe original NFD and the NFD with congestion feedback measuremen-t. Therefore, a new method to improve the measurement process isrequired.

Method 1 to Improve Performance In the congestion feedback mea-surement of NFD in the previous sections, the congestion feedback wascalculated for all NDN packets before being added to the NDNLPv2Header and then transferred. However, in the case of a video applica-tion (the main target of this project), acquiring the congestion feedbackvalue at intervals of several seconds is sufficient. Therefore, it is con-ceivable to shorten the processing time of the entire stream by acquiringcongestion feedback measurement in NFD only at regular time intervalsas shown in Figure 31.


NFD(B)

2NFD(C)

NFD(A)

3 1 23 1

Producer Consumer

23

1

23

1

NDNLPv2 Header

NDN Data

SELECT and ADDtarget packets

UPDATEtarget packets

UPDATEtarget packets

Synchronization ? Synchronization ?

Figure 31: Intermittent congestion feedback measurement process

However, in this method, the following problems arise:

• NFD needs to recognize that it is connected to the Producer (itis in the immediate vicinity of the data source)

• It is necessary to manage the time interval (the timing to addthe congestion feedback value to the NDNLPv2 header) for everyName Prefix in the Data

• When a large number of data streams pass through the same Face,the processing will not be done at regular intervals

Due to the problems above, it was concluded that it will be difficult torealize performance improvement through this method.

Method 2 to Improve Performance In this method, a way to short-en the processing time per packet with the NDNLPv2 Header beingattached to all NDN packets (adding congestion feedback value) willbe investigated. The measurement of the congestion feedback can belargely broken down into 2 components, namely,

(a) Calculating congestion feedback value by extracting the transferrate and queue length from the network interface;

(b) Append congestion feedback value to NDNLPv2 Header and thenadding it to the data packet;

where processing of (a) accounts for most of the processing time. Thetransfer speed and the queue length are acquired using libnl3 whichcommunicates with the kernel using the NETLINK socket. This com-munication process takes time and it cannot be shortened without mod-ifying libnl3. Due to this, it was proposed that the number of times


that the libnl3 was used to obtain the transfer speed and queue lengthinformation be reduced so as to decrease the time taken for the com-munication process with the kernel.

In order to do so, the congestion feedback value is only calculated pe-riodically at a fixed interval so that the libnl3 is only used intermittently.This reduces the overhead as communication with the kernel only takesplace at a fixed interval. On the other hand, the data packets thatare transmitted between the intervals are all appended with the samecongestion feedback value. The process is as shown in Figure 32 belowwhere each NFD autonomously appends the same congestion feedbackvalue to the data packets at regular intervals.

NFD23 1 23 156 4 56 4

同じ輻輳プライス値同じ輻輳プライス値Same congestion feedback value

Figure 32: Appending the same congestion feedback value for data packets atregular intervals

The results measured by NFD after correction are shown in the fourthand fifth columns of Table 3. As seen from the results in the table, it ispossible to achieve a level of performance comparable with the originalNFD by adjusting the time interval parameter.

4.2 High-speed Software Router

Realizing a high-speed software-based ICN router, which is built on ahardware platform based on a commercial off-the-shelf (COTS) com-puter, is one of essential issues to support our futuristic ICN2020 ap-plications, such as video delivery. Since significant efforts have beendirected toward sophisticated data structures and algorithms for ICNrouters, we have enough design choices for realizing high-speed ICNpacket forwarding, such as trie-based and hash table-based data struc-tures and algorithms. Despite their successes, most of the data struc-tures and algorithms are not specialized for performing on computers,which have slow memory devices, i.e., dynamic random access memo-ries (DRAMs). Data structures and algorithms for high-speed softwareNDN routers must be selected from the perspectives of the DRAMaccesses as well as their time complexity. In this work, we design a


Table 3: Processing overhead of congestion feedback measurement

NFD with NFD with NFD with

congestion congestion congestion

Original feedback feedback feedback

No. NFD measurement measurement measurement

(sec) (sec) *Before (sec) *After (sec) *After

modification modification modification

[Interval = 4 sec] [Interval = 1 sec]

1 632 719 636 637

2 629 722 636 637

3 636 718 634 635

4 634 717 635 637

5 636 712 634 640

Average

processing 633 718 635 637

time (sec)

Average

throughput 22 19 22 22

(Mbps)


reference forwarding engine by carefully selecting data structures forhigh-speed software ICN router, and then analyzes a prototype imple-mented according to the design to know its performance bottleneck.Microscopic analyses at the level of CPU pipelines and instructions re-veal that DRAM access latency is one of bottlenecks for high-speedforwarding engines. Finally, the paper designs several prefetch-friendlypacket processing techniques to hide DRAM access latency. The pro-totype according to the prefetch-friendly packet processing techniquesachieves more than 40 million packets per second packet forwarding ona COTS computer.

Status: The paper is under submission.

4.3 Experience with testbeds

In this section, side projects regarding experiences working with ICNtestbeds and the GTS service are reported. The projects are used toobtain knowledge and information on the proposed tools to be used asguidelines in experiments design and testbeds configuration.

Measuring video retrieval time in Named Data Networking The aim of thework is to measure video retrieval time of different globally connectedconsumer nodes over NDN Testbed by enabling and disabling cachingscenario.Student’s project (Nov 2017 - Feb 2017).

Evaluation of state of the art works on SDN/NFV Placement and Load Bal-

ancing This project evaluates the state of the art works on SDN/NFVplacement and load balancing including the performance analysis ofClick-based middleboxes. These concepts were prototyped with RyuOpenFlow Controller along with the CPLEX optimization tool for loadbalancing and tested on the GEANT Testbed Services (GTS).Master’s thesis (Sep 2017 - May 2017).

Open SDN Testbed: Realize the SDN testbed and automation of network

topologies using the EU GEANT Testbed services The purpose of thisproject is to analyze and test the GEANT Testbed (GTS), identifyingthe constraints of the GTS testbed as well as the challenges and diffi-culties in deploying different network topologies, in order to contributeto the research community with automation tools that can help achieverapid prototyping, deployment and test verification of SDN networksfor various network topology configurations, like Datacenter FatTree,Full-Mesh and other models. Another important goal is to scale virtual


resources over the GTS resources assigned to us, thus solving the issueof limitation, through the implementation of a testbed comprised of aSDN controller, a network hypervisor, openflow switches, and virtualmachines, leveraging various technologies in the process, in order todetermine which are best coupled with GTS.Student’s project (Jan 2017 - May 2017).Status: A paper based on this project is under submission.

Evaluation of NDN experiments deployment over GTS: ChronoChat sync-

state delay This project represents our first tentative of an ICN deploy-ment over GTS. The use-case selected is the evaluation of the delay inthe synchronization of the state in the ChronoChat application imple-mented over NDN. The experiments are designed to evaluate the sync-state delay in different network topologies and simulating the situationof temporary off-line nodes. Results from both local and distributeddeployments (using a GTS-based testbed) are analyzed and compared,showing benefits and drawbacks of the use of GTS platform.Status: Master’s thesis (ongoing)

Comparison of video delivery performance over different ICN networks using

GTS testbed This project aims to give a complete analysis of the actualprotocols for video delivery available in ICN networks. For comparison,both application from NDN and CICN are taken in consideration. Thedeployments of the experiments are executed on top of a GTS-basedglobal testbed, allowing a fair comparison of the different protocolsusing the exact same network topologies and resources. The projectwill test out the ability of GTS-based testbed to support video deliv-ery experiments, identifying eventual bottlenecks and limitations of theplatform.Status: Student’s thesis (ongoing)


5 Ongoing and future activities

As future activities, we plan to increase the effort in term of joint col-laborations. Two main activities are already ongoing:

• Global-scale CUTEi deployment. A connection between differen-t locations in Japan (KDDI, KKE, OSU and OCU) has alreadyestablished. We are working on enabling the connection with theeuropean node in UGOE to realize some global-scale scenarios (SeeFig.33).

Figure 33: Use-case scenarios for CUTEi global deployment

• Video streaming experiments using CICN tools. Tools from CICNproject(i.e., DASH player and networking monitoring tools, seeFig. 34) will be used in conjunction with the application andprototypes developed in this project (See WP2 and WP3). Theexperiments will be especially focus on the use of ICN paradigm forAdaptive bitrate (ABR) streaming, and will make make use to theemulation tools parts of the CICN project to analyze the outcomeof the experiments in presence of heterogeneous connections (e.g.,LTE, Wi-fi, etc..).


Figure 34: Example of CICN tools for video streaming experiments


References

[1] M. Mosko et al., “CCNx Messages in TLV Format.” [Online]. Avail-able: https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-03

[2] ——, “CCNx Semantics.” [Online]. Available: https://tools.ietf.org/html/draft-irtf-icnrg-ccnxsemantics-03

[3] V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H.Briggs, and R. L. Braynard, “Networking named content,” in Pro-ceedings of the 5th International Conference on Emerging Network-ing Experiments and Technologies, ser. CoNEXT’09. ACM, Dec.2009, pp. 1–12.

[4] “CCN/NDN Convergence Effort at IRTF ICN Research Group.”[Online]. Available: https://trac.ietf.org/trac/irtf/wiki/icnrg/convergence

[5] P. Gusev and J. Burke, “Ndn-rtc: Real-time videoconferencing overnamed data networking,” in Proceedings of the 2nd InternationalConference on Information-Centric Networking. ACM, 2015, pp.117–126.

[6] Z. Lailari, H. B. Abraham, B. Aronberg, J. Hudepohl, H. Yuan,J. DeHart, J. Parwatikar, and P. Crowley, “Experiments with theemulated ndn testbed in onl,” in Proceedings of the 2nd Interna-tional Conference on Information-Centric Networking. ACM, 2015,pp. 219–220.

[7] A. Compagno, M. Conti, P. Gasti, L. V. Mancini, and G. Tsudik,“Violating consumer anonymity: Geo-locating nodes in named datanetworking,” in 13th International Conference on Applied Cryptog-raphy and Network Security (ACNS 2015), 2015.

[8] Y. Yu, A. Afanasyev, D. Clark, V. Jacobson, L. Zhang et al.,“Schematizing trust in named data networking,” in Proceedings ofthe 2nd International Conference on Information-Centric Network-ing. ACM, 2015, pp. 177–186.

[9] A. Afanasyev, C. Yi, L. Wang, B. Zhang, and L. Zhang, “Snamp:Secure namespace mapping to scale ndn forwarding,” in Comput-er Communications Workshops (INFOCOM WKSHPS), 2015 IEEEConference on. IEEE, 2015, pp. 281–286.


d4.1: 1st yearly wp4 report & demonstration - gwdg · vpp vector packet processing cicn...

Documents