On Pending Interest Table in Named Data Networking Huichen Dai, Bin Liu, Yan Chen*, Yi Wang Tsinghua University, China *Northwestern University, USA

Outline Background of Named Data Networking (NDN) Pending Interest Table (PIT) Problem Statement Challenges Measure PIT Size and Access Frequency NCE to Accelerate PIT Access and Size Shrinking Evaluation Conclusion

Background of NDN (1/3) Newly proposed clean-slate network architecture; Embraces Internet’s function transition from host-to-host communication to content dissemination; Routes and forwards packets by content names; Two kinds of packets: Interest packet and Data packet. Request-driven communication model (pull);

Background of NDN (2/3) Content Store (CS): the router’s buffer memory that caches Data packets; Pending Interest Table (PIT): each entry records the name of a pended Interest and the interfaces from which the Interest comes in. Forwarding Information Base (FIB): NDN forwarding table.

Background of NDN (3/3) Content Store Forwarding Information Base Pending Interest Table Figure: Interest Packet lookup and forwarding process Figure: Data packet lookup and forwarding process

Pending Interest Table (1/3) A special table in NDN and no equivalent in IP. Keeps track of the Interest packets that are received but yet un-responded. Brings NDN significant features: communication without the knowledge of host locations; loop and packet loss detection; multipath routing support; etc.

Pending Interest Table (2/3) Read and write on PIT. Interest Packet Data Packet com/google/maps lookup com/google/maps/data/1/ com/google/scholar com/google/scholar/data/1/ PIT Content name Interface list inserted 1 deleted inserted 3 deleted ...... …… A Dynamic Process!

Problem Statement (1/2) A router inserts every incoming Interest into PIT, and removes each received Data packet from PIT. High-speed packet arrival rate leads to a large PIT size and extremely high access (lookup, insert and delete) frequency. Two major problems about PIT arise: The size of PIT? The access (lookup, insert and delete) frequency of PIT? Size? Frequency?

Problem Statement (2/2) Senior researchers (Lixia Zhang, Van Jacobson, etc.) witness Internet’s function transition; NDN is empirically proposed based on their experience; A gap from experience to practice: can PIT be satisfied by off-the-shelf technologies? No previous study touched the feasibility issue. No statistics support.

Challenges No NDN deployment; No data; No PIT;

A fresh look at NDN (1/2) -- from application perspective NDN better satisfies the requirements of users: browsing web pages, watching videos, sharing files, etc. Users demand the same network applications, but require different implementations in NDN. The PIT entries are consumed by application-triggered requests.

parc.com/email_service/van/example@gmail.com/123 A fresh look on NDN (1/2) -- PIT entry filled by app-triggered Interests A sample PIT: PIT Content name Interface list com/google/maps 1 HTTP Interest com/google/scholar 3 Avatar 2 P2P Interest parc.com/email_service/van/example@gmail.com/123 5 Email Interest …… …… The applications do not change, solve the problems from the application perspective!

Apps from IP to NDN (1/5) Major Internet applications: HTTP, FTP, P2P, Email, Online games, Streaming media, Instant messaging, etc. Implement these applications using NDN’s request-driven communication model. Afterwards, examine how these applications construct and destruct PIT entries. HTTP/1.1 as an example.

Apps from IP to NDN -- HTTP (2/5) A request/response protocol; A client sends a request over a connection to a server, The server responds with a message. HTTP/1.1 adopts Persistent Connections: HTTP requests and responses can be pipelined on a connection. Simplest Case:

Apps from IP to NDN -- HTTP(3/5) However, the actual case is complicated. For HTTP Response: HTTP response divided into multiple Data packets due to the MTU, At 𝑡 0 the corresponding PIT entry is created, and at 𝑡 𝑛 the entry is removed, Entry Lifetime: 𝑡 𝑛 − 𝑡 0 .

Apps from IP to NDN -- HTTP(4/5) For HTTP Request: HTTP requests can be divide into different categories, including GET, HEAD, POST, PUT, DELETE, TRACE; GET, HEAD – pull data from server; POST, PUT – push data to server; DELETE, TRACE – function calls on the server. NDN can only pull data from server.

Apps from IP to NDN -- HTTP(5/5) GET, HEAD – implemented by Interest packet directly; Extend the function of Interest packet to accommodate the rest methods; POST, PUT – add additional data block to the Interest packet that contains the content to be pushed to the server; DELETE, TRACE – extend Interest packet to enable function calls.

Measure PIT Size and Access Freq. (1/3) So far, we have So we can: We get data – we quantify PIT size and access frequency by analyzing the NDN trace. Applications on IP Applications on NDN IP trace NDN trace translate

Measure PIT Size and Access Freq. – Metrics (2/3) Size: the number of PIT entries at each snapshot by examining the lifetime of each PIT entry. Lookup frequency: the # of Data packets (excluding the last Data of a request/response pair) arrive per second; Insert frequency: the # of emerging biflows (new Interests arrive) Delete frequency: the # of disappearing biflows (last Data packet of a request/response pair arrive).

Measure PIT Size and Access Freq. – Results (3/3) A one-hour IP trace from a 20 Gbps link in China Education and Research Network (CERNET). PIT size: 1.5 million Frequencies of the first 10 seconds: (1.4 M/s, 0.9 M/s, 0.9 M/s) Methodology is what matters.

Data Structure for PIT (1/3) PIT size and access frequency demand a well-organized data structure to implement PIT. Inspired by the Trie structure in IP lookup, we organize PIT by a Trie as well. A sample IP trie, bit-wise.

Data Structure for PIT (2/3) NDN name is different from IP address; IP addresses: Fixed length, short… NDN names: hierarchical, composed of component, enables aggregation; Unbounded # of components, much longer than IP; E.g., /com/parc/bulletin/breakthroughs.html Therefore, we adopt Name Prefix Trie, which is of component granularity.

Data Structure for PIT (3/3) 1 2 9 3 7 A D com cn 4 5 8 B E yahoo google baidu maps map news 6 uk level-1 level-5 level-2 level-4 level-3 C sina Name Ports /com/yahoo 1 /com/yahoo/news /com/yahoo/maps/uk 2 /com/google /com/google/maps 1, 2 /cn/google/maps 3 /cn/sina 2, 3 /cn/baidu 4 /cn/baidu/map An example of PIT Name Prefix Tree Name Prefix Trie (NPT), each edge stands for a name component.

Name Component Encoding (1/4) The Name Prefix Trie (NPT) makes PIT well organized, but matching each component is slow: The length of each component varies; should be an exact match of string patterns. We further propose to use positive integers to encode components – Name Component Encoding (NCE). An integer occupies smaller memory space compared to a component; Matching integers is much faster.

Name Component Encoding (2/4) 1 2 9 3 7 A D com cn 4 5 8 B E yahoo google baidu maps map news 6 uk level-1 level-5 level-2 level-4 level-3 C sina Name Prefix Tree Encode Name Prefix Tree CAS Name Prefix Trie (NPT) is transferred to Encoded Name Prefix Trie (ENPT).

Name Component Encoding (3/4) Preparation: define the edges in the NPT leaving from the same node as a Code Allocation Set (CAS) (dotted ellipse on the NPT); The rules to assign codes to components: Assign each name component in a CAS a unique code; The code should be as small as possible (ensures the codes are continuous). The ENPT is a logical structure and is eventually implemented by Simplified State Transition Arrays (S2TA). Benefit: a component match on S2TA can be implemented by a single memory access with the codes as indexes!

Name Component Encoding (4/4) 1 2 9 3 7 A D 4 5 8 B E 6 level-1 level-5 level-2 level-4 level-3 C Simplified State Transition Array (S2TA) Encode Name Prefix Trie (ENPT) The data structure that really implements the ENPT, each transition stands for a node and its outgoing edges. The codes are indexes of each outgoing edge.

Evaluation Two name sets to compose two PITs: Evaluation goals: Domain names collected from ALEXA, DMOZ and our web crawler, around 10 Million; URLs extracted from the HTTP requests in the trace, around 8 Million. Evaluation goals: memory consumption of S2TA, access frequency S2TA, Comparison with other methods.

Evaluation Results (1/3) Memory Consumption Figure: 10M Name Set memory consumption–original size, NPT size, ENPT. compression ratio (10M Name Set): 63.66% Figure: 8M Name Set memory consumption–original size, NPT size, ENPT. compression ratio (8M Name Set): 12.56%

Evaluation Results (2/3) Access frequency Figure: Lookup, insert and delete performance for the 10M Name Set Average: 3.27 M/s, 2.93 M/s and 2.69 M/s Figure: Lookup, insert and delete performance for the 8M Name Set Average: 2.51 M/s, 1.81 M/s and 2.18 M/s

Evaluation Results (3/3) Figure: PIT access frequency speedup based on S2TA. All these results reveal that PIT can be implemented by off-the-shelf technologies.

Conclusion Measure the size and access frequency of a specific PIT; Prove the feasibility of PIT with off-the-shelf technologies; Propose NCE to accelerate PIT access operations while reducing PIT size.

Thanks! Questions please ^_^