A Transport Layer and Socket API for (h)ICN Design, Implementation and Performance Analysis Mauro Sardara, Luca Muscariello, Alberto Compagno ACM ICN 2018 September 23rd 2018

This paper is not about a new transport protocol for (h)ICN Disclaimer This paper is not about a new transport protocol for (h)ICN This paper describes a transport framework developers can use for (h)ICN application development (h)ICN = {NDN, CCN, hICN1} Transport services and API Remove outline [1] Luca Muscariello et.al., "Hybrid Information-Centric Networking, Internet Area WG, Internet-Draft, https://datatracker.ietf.org/doc/ draft-muscariello-intarea-hicn", June 2018

Does ICN need a transport framework? Common trend on ICN: writing application directly on top of the network layer: Packet-level control of the communication Application developers forced to deal with: Congestion control Segmentation and reassembly Crypto operations … Not always easy to implement Discourage developers from writing ICN application Be more clear about separation application – transport tasks Put a limit on ICN adoption

Does ICN need a transport framework? Applications want to exchange Data Unit in a simple way Typically without dealing with the network Requirements: A transport layer providing services to them A simple way to access these services One of the reasons of the success of TCP/IP has been the development of a transport framework and a simple Socket API allowing application developers to communicate through the network as if they were writing to a file A transport layer and a clean socket API for ICN could enhance its adoption and simplify the development of new application

Separation between transport services and application logic Simple Socket API enhancing portability and integration Performance and efficiency Evolutionary deployment of ICN into existing applications Security: authentication and integrity as built-in transport services Design principles Why a socket library? For many reasosn. Here we analyze the application point of view Applications are relieved from the task of managing L4 problems such as Segmentation and congestion control Applications deal just with ADUs and do not have to manage the PDUs Consistency: Different applications use the same interface for dealing with repeated problem

Transport Services Application Logic Application ADU Transport Transport framework Transport Segmentation Authentication Naming Integrity Reassembly Verification Congestion Control Fetching Producer Services Consumer Services L3 PDU (I/D) Forwarding Engine Routing and Forwarding First, we have the application. Application deals just with ADU, no interest and data are processed by applications. They can still process them, but through some hook they put inside the library. Second, the Socket Library: it process L3/4 messages, interest and data, and prepares application data units for applications. The socket library then talks with the ICN forwarder, by sending and receiving interest and data. The services offered by the library can be easily separate in 2 groups: the first group contains the services for a producer application, while the second contains the services used by a consumer application. Since they are orthogonal, we can split the generic transport socket into 2 unidirectional sockets: the consumer socket and the producer socket.

ICN Socket API How transport services are exposed to applications? BSD-like socket API Based on socket interface extension for IPv61 icn_socket(), icn_sendto(), icn_recvmsg(), icn_bind(), icn_setsockopt()… New address family: AF_ICN Socket types: SOCK_CONS and SOCK_PROD Protocol types: CONS_REL/CONS_UNREL and PROD_REL/PROD_UNREL Simple, clear and widely adopted Easier to insert into current applications 1. Basic Socket Interface Extensions for IPv6. Technical Report 3493. https://rfc-editor. org/rfc/rfc3493.txt

Producer Socket Consumer Socket Application (e.g. HTTP Server) Application (e.g. HTTP Client) icn_sendto() icn_recvmsg() icn_recvfrom() Segmentation Naming Reassembly Data Retrieval Protocol Miss Integrity Authentication Interests can be satisfied directly at the transport layer Integrity/Auth Check Data Output Buffer Interest Input Buffer Hit Interest Output Buffer Data Input Buffer Add discussion of the data output buffer placement + implications (security, producer authentication with the forwarder….) Data Packets Interests Interests Data Packets

Performance and Efficiency Transport framework implemented as C++ library VPP1 integration Full userspace implementation Shared memory between transport framework and L3 forwarder No context switching overhead Manifest support: amortized crypto operations cost [1] White Paper - Vector Packet Processing - One Terabit Software Router on Intel Xeon Scalable Processor Family Server. https://fd.io

Authentication and Integrity Native security features, transparently offered to each application 2 Approaches: Manifest authentication vs per packet authentication Manifest Authentication Per Packet Authentication Data Packet 1 Data Packet 1 Signed Manifest Data Packet 2 Data Packet 2 Signed Data Packet Data Packet 3 Data Packet 3 Data Packet 4 Data Packet 4 Integrity verified with HASH inside Signed Manifest. Integrity verified with the signature itself Remind the bottleneck is the hash verification, not the signature (in the manifest case)

Performance Evaluation How do basic ICN security services (authentication and integrity) affect the communication? What benefits can an ICN-based transport framework bring to existing applications?

Crypto operations impact Comparison: Consumer goodput w/ crypto Consumer goodput w/o crypto Cisco UCS Type-C Intel(R) Xeon(R) CPU E5-2695 v4 256 GB of RAM Intel 82599ES 10-Gbps NIC 10Gbps Cisco-Nexus 5k 1500 Byte MTU No hardware offloading UCS 1 Consumer VPP Nexus UCS 2 Producer VPP

Crypto operations impact Change colors Motivate TCP comparison Hardware offloading - Highlight hardware offloading need Remind theoretical limit Add inline comments (1) Results at the time of the writing, now ~ 5.5 Gbps.

ICN Evolutionary deployment: benefits for existing apps DASH linear video distribution Video traffic on the internet ~ 82 %1 Scalability challenge for content providers (e.g. Verizon) Servers need to manage hundreds of thousand of TCP sessions Heavy CPU and memory impact Current solution: horizontal scaling Can we improve the current video delivery system? ICN transport framework can provide multicast to applications One socket per channel instead of one socket per user Explain better the experiment (what is DASH video distribution, why we used this…) Add statisics about DASH video distribution, describe problem before, cite Verizon 1 Cisco Visual Networking Index: Forecast and Methodology - 2017

(h)ICN producer transport vs TCP transport E.g. live content broadcasting of popular content Video Server One socket per video channel Video Server n socket for n clients Transport layer Stateless Stateful Producer Socket … Video Segment S S S S S S S Pull Based Clients requesting same video channel Interest Push Based … … U1 U2 U3 U4 Un-2 Un-1 Un U1 U2 U3 U4 Un-2 Un-1 Un

Experiment Setup Cluster of 150 clients connected to an ICN enabled Apache Traffic Server (ATS) HTTP Reverse Proxy, 2 GB cache, nginx origin server serving 48 channels Each client requests one of the 48 available channels (zipf distribution, ⍺=1.4/0.7), using the congestion control algorithm published in [1] An HTTP Request can be directly served by the transport (rather than by ATS), if the corresponding Response has been already published in the Producer socket output buffer [1] G. Carofiglio, et al. "Multipath congestion control in content-centric networks"

Scalability Results Change colo The video distribution scales with the number of active channels instead of the number of active users as using a TCP/IP network.

Previous work Consumer-producer API for named data networking. ICN (2014) No built-in security services – Signature and verification left to applications No evaluation CCNx Transport Library No support for producer services Limited API NaNET: socket API and protocol stack for process-to-content network communication. ICN (2014). Not clear how to access transport services such as authentication Underline the fact there is not evaluation. Is it feasible? None of these works has been adopted in the ICN implementations.

Conclusions General transport framework for ICN applications Fast userspace implementation based on VPP and DPDK API allowing extensions and integration in today applications Significant impact of crypto operations on overall transport performance Possible improvement with hardware offloading (e.g. Intel OAT acceleration) Benefits of ICN transport services in today’s application (DASH) Prototype available soon on FD.io (https://wiki.fd.io/view/Cicn) Supported Platforms: Ubuntu, CentOS, MacOS Add final slide with summary Add operations of the transport (sharable among many apps), underlying it is convenient to have there in the transport Reference of the new results Remind people there is a framework they can contribute and use, open source..