ETRI Bloom Filter-based Flat Name Resolution System for ICN ICNRG Interim meeting, Paris Jungha Hong, Woojik Chun, and Heeyoung Jung September 27, www.idnet.re.kr1

ETRI Contents Review of last draft Updated parts Implementation issues –False positive probability (FPP) –Bloom filter (BF) size www.idnet.re.kr2

ETRI Background In ICN, location independent and flat name is assumed The binding between name and locator is required for lookup-by-name routing –Name resolution system (NRS) –Maintains and resolves the bindings The most important challenge on designing NRS is scalability on the ever-increasing number of named data object (NDO) Bloom filter-based NRS (B-NRS) is proposed –We utilize the hierarchical structure of B-NRS and bloom filter Constructs a network of B-NRS servers, which consists of a forest by several disjoint trees Bloom filter as an aggregated form of names is announced instead of announcing the whole list of names

ETRI Bloom filter-based NRS (B- NRS) B-NRS structure A network of B-NRS servers Relationships of parent-child and peering B-NRS server components Peering : B-NRS Server Name lookup table Bloom filters (BFs) for its own, from child, and from peer BF for its own BF from child 1 BF from child 2 BF from peer 1 BF from peer 2 Announce to parents & peers Bitwise OR Lookup table NameLocator(s) Name 1 LOC 1 Name 2 LOC 2-1, LOC www.idnet.re.kr4 B-NRS server

ETRI Name registration (1) No constraints –Flat names can be registered to any arbitrary B-NRS server Followed by BF updates : insert-through No BF update when name is deleted –BF cannot handle deletion –Use periodic refresh www.idnet.re.kr5

ETRI Name registration (2) www.idnet.re.kr6 S1 S3 S2 S7 S6 S5 S4 Peering Registration BF Update S : B-NRS server

ETRI Locator update When a NDO presents(depresents) into(from) the network, only locator information is inserted(deleted) into(from) lookup table –No effects on BFs and structure of B-NRS –Inherently supports mobility www.idnet.re.kr7 NameLocator(s) N1LOC1 N2LOC2-1, LOC2-2 N3- N4LOC4-1, LOC4-2, LOC4-3

ETRI Lookup (1) Through the BF test for the given name, locator lookup request is forwarded into the B-NRS server where the binding is actually stored –BF is a role of forwarding table Request message is forwarded into all child and peers which return positive answers –If none of BFs returns positive answer, then it is forwarded into parent Reply takes the reverse path of the request www.idnet.re.kr8

ETRI Lookup (2) www.idnet.re.kr9 S1 S3 S2 S7 S6 S5 S4 Peering Request message Reply message Nack

ETRI Comparison with other NRS (1) www.idnet.re.kr10 NRS Distributed NRS DHT-based NRS -MF-DMap -SAIL-MDHT B-NRS Centralized NRS

ETRI Comparison with other NRS (2) www.idnet.re.kr11

ETRI Analysis of BF size and FPP n is the # of names in a BF m is the size of BF k is the # of hash functions In lower tier: –n=1K, m=8Kb  m/n = 8, k = 5.4  FPP = 0.02 (2%) 1K servers with 1K entries for each  1M entries  1MB memory for FPP=0.02 In higher tier: –n = 1M, m = 16Mb  m/n = 16, k =  FPP = (0.046%) 1M servers with 1M entries for each  1T entries  2TB memory for FPP= www.idnet.re.kr12

ETRI Can we reduce the amount of memory? Need to invent algorithm for –Insert, refresh, lookup Name  5(6) hash values  memory chunk –Structuring memory hierarchy (TCAM with DRAM) –Consider the possibility of using GPU www.idnet.re.kr13

ETRI Lookup www.idnet.re.kr14 BF for Child 1 BF for Child 2 BF for Child 3 BF for Child p BF for Peer 1 BF for Peer 2 BF for Peer q } All 1’s match List of Children & Peers BF for Name May implement with TCAM or GPU Multicast, Iterative, or Random Query Distribution BF for its own p children q peers

ETRI Design choice – ongoing work Same or different hash functions –Rehash in every server ? How many children and peers –Many servers have the limited no. of names How many levels (tiers) –Not so deep –Related with query distribution overhead H/W assisted implementation –TCAM or GPU –Performance for higher level server www.idnet.re.kr15

ETRI www.idnet.re.kr16 Questions or Comments