15-829A/18-849B/95-811A/19-729A Internet-Scale Sensor Systems: Design and Policy Lecture 9 – Lookup Algorithms (DNS & DHTs)

Lecture # Overview Lookup Overview Hierarchical Lookup: DNS Routed Lookups  Chord  CAN

Lecture # The Lookup Problem Internet N1N1 N2N2 N3N3 N6N6 N5N5 N4N4 Publisher Key=“title” Value=MP3 data… Client Lookup(“title”) ? Problem in DNS, P2P, routing, etc. Sensor networks: how to find sensor readings?

Lecture # Centralized Lookup (Napster) Client Lookup(“whale”) N6N6 N9N9 N7N7 DB N8N8 N3N3 N2N2 N1N1 SetLoc(“whale”, N4) Simple, but O( N ) state and a single point of failure Key=“whale” Value=image data… N4N4

Lecture # Hierarchical Queries (DNS) N4N4 Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Scalable (log n), but could be brittle Key=“whale” Value=image data… Lookup(“whale”) Root

Lecture # Flooded Queries (Gnutella, /etc/hosts) N4N4 Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Robust, but worst case O( N ) messages per lookup Key=“whale” Value=image data… Lookup(“whale”)

Lecture # Routed Queries (DHTs) N4N4 Publisher Client N6N6 N9N9 N7N7 N8N8 N3N3 N2N2 N1N1 Lookup(“whale”) Key=“whale” Value=image data… Scalable (log n), but limited search styles

Lecture # Overview Lookup Overview Hierarchical Lookup: DNS Routed Lookups  Chord  CAN

Lecture # Obvious Solutions (1) Objective: provide name to address translations Why not centralize DNS? Single point of failure Traffic volume Distant centralized database Single point of update Doesn’t scale!

Lecture # Obvious Solutions (2) Why not use /etc/hosts? Original Name to Address Mapping  Flat namespace  /etc/hosts  SRI kept main copy  Downloaded regularly Count of hosts was increasing: machine per domain  machine per user  Many more downloads  Many more updates

Lecture # Domain Name System Goals Basically building a wide area distributed database Scalability Decentralized maintenance Robustness Global scope  Names mean the same thing everywhere Don’t need  Atomicity  Strong consistency

Lecture # DNS Records RR format: (class, name, value, type, ttl) DB contains tuples called resource records (RRs)  Classes = Internet (IN), Chaosnet (CH), etc.  Each class defines value associated with type FOR IN class: Type=A  name is hostname  value is IP address Type=NS  name is domain (e.g. foo.com)  value is name of authoritative name server for this domain Type=CNAME  name is an alias name for some “canonical” (the real) name  value is canonical name Type=MX  value is hostname of mailserver associated with name

Lecture # DNS Design: Hierarchy Definitions root edunet org ukcom gwuucbcmubu mit cs ece cmcl Each node in hierarchy stores a list of names that end with same suffix Suffix = path up tree E.g., given this tree, where would following be stored: Fred.com Fred.edu Fred.cmu.edu Fred.cmcl.cs.cmu.edu Fred.cs.mit.edu

Lecture # DNS Design: Zone Definitions root edunet org ukcom ca gwuucbcmubu mit cs ece cmcl Single node Subtree Complete Tree Zone = contiguous section of name space E.g., Complete tree, single node or subtree A zone has an associated set of name servers

Lecture # DNS Design: Cont. Zones are created by convincing owner node to create/delegate a subzone  Records within zone stored multiple redundant name servers  Primary/master name server updated manually  Secondary/redundant servers updated by zone transfer of name space Zone transfer is a bulk transfer of the “configuration” of a DNS server – uses TCP to ensure reliability Example:  CS.CMU.EDU created by CMU.EDU administrators

Lecture # Servers/Resolvers Each host has a resolver  Typically a library that applications can link to  Local name servers hand-configured (e.g. /etc/resolv.conf) Name servers  Either responsible for some zone or…  Local servers Do lookup of distant host names for local hosts Typically answer queries about local zone

Lecture # DNS: Root Name Servers Responsible for “root” zone Approx. dozen root name servers worldwide  Currently {a-m}.root- servers.net Local name servers contact root servers when they cannot resolve a name  Configured with well- known root servers

Lecture # Lookup Methods Recursive query: Server goes out and searches for more info (recursive) Only returns final answer or “not found” Iterative query: Server responds with as much as it knows (iterative) “I don’t know this name, but ask this server” Workload impact on choice? Local server typically does recursive Root/distant server does iterative requesting host surf.eurecom.fr gaia.cs.umass.edu root name server local name server dns.eurecom.fr authoritative name server dns.cs.umass.edu intermediate name server dns.umass.edu 7 8 iterated query

Lecture # Typical Resolution Client Local DNS server root & edu DNS server ns1.cmu.edu DNS server NS ns1.cmu.edu NS ns1.cs.cmu.edu A www=IPaddr ns1.cs.cmu.edu DNS server

Lecture # Typical Resolution Steps for resolving  Application calls gethostbyname() (RESOLVER)  Resolver contacts local name server (S 1 )  S 1 queries root server (S 2 ) for (  S 2 returns NS record for cmu.edu (S 3 )  What about A record for S 3 ? This is what the additional information section is for (PREFETCHING)  S 1 queries S 3 for  S 3 returns A record for Can return multiple A records  what does this mean?

Lecture # Workload and Caching What workload do you expect for different servers/names?  Why might this be a problem? How can we solve this problem? DNS responses are cached  Quick response for repeated translations  Other queries may reuse some parts of lookup NS records for domains DNS negative queries are cached  Don’t have to repeat past mistakes  E.g. misspellings, search strings in resolv.conf Cached data periodically times out  Lifetime (TTL) of data controlled by owner of data  TTL passed with every record

Lecture # Prefetching Name servers can add additional data to any response Typically used for prefetching  CNAME/MX/NS typically point to another host name  Responses include address of host referred to in “additional section”

Lecture # Typical Resolution Client Local DNS server root & edu DNS server ns1.cmu.edu DNS server NS ns1.cmu.edu NS ns1.cs.cmu.edu A www=IPaddr ns1.cs.cmu.edu DNS server

Lecture # Subsequent Lookup Example Client Local DNS server root & edu DNS server cmu.edu DNS server cs.cmu.edu DNS server ftp.cs.cmu.edu ftp=IPaddr ftp.cs.cmu.edu

Lecture # Reliability DNS servers are replicated  Name service available if ≥ one replica is up  Queries can be load balanced between replicas UDP used for queries  Need reliability  must implement this on top of UDP!  Why not just use TCP? Try alternate servers on timeout  Exponential backoff when retrying same server Same identifier for all queries  Don’t care which server responds Is it still a brittle design?

Lecture # Overview Lookup Overview Hierarchical Lookup: DNS Routed Lookups  Chord  CAN

Lecture # Routing: Structured Approaches Goal: make sure that an item (file) identified is always found in a reasonable # of steps Abstraction: a distributed hash-table (DHT) data structure  insert(id, item);  item = query(id);  Note: item can be anything: a data object, document, file, pointer to a file… Proposals  CAN (ICIR/Berkeley)  Chord (MIT/Berkeley)  Pastry (Rice)  Tapestry (Berkeley)

Lecture # Routing: Chord Associate to each node and item a unique id in an uni-dimensional space Properties  Routing table size O(log(N)), where N is the total number of nodes  Guarantees that a file is found in O(log(N)) steps

Lecture # Aside: Consistent Hashing [Karger 97] N32 N90 N105 K80 K20 K5 Circular 7-bit ID space Key 5 Node 105 A key is stored at its successor: node with next higher ID

Lecture # Routing: Chord Basic Lookup N32 N90 N105 N60 N10 N120 K80 “Where is key 80?” “N90 has K80”

Lecture # Routing: Finger table - Faster Lookups N80 ½ ¼ 1/8 1/16 1/32 1/64 1/128

Lecture # Routing: Chord Summary Assume identifier space is 0…2 m Each node maintains  Finger table Entry i in the finger table of n is the first node that succeeds or equals n + 2 i  Predecessor node An item identified by id is stored on the successor node of id

Lecture # Routing: Chord Example Assume an identifier space 0..8 Node n1:(1) joins  all entries in its finger table are initialized to itself i id+2 i succ Succ. Table

Lecture # Routing: Chord Example Node n2:(3) joins i id+2 i succ Succ. Table i id+2 i succ Succ. Table

Lecture # Routing: Chord Example Nodes n3:(0), n4:(6) join i id+2 i succ Succ. Table i id+2 i succ Succ. Table i id+2 i succ Succ. Table i id+2 i succ Succ. Table

Lecture # Routing: Chord Examples Nodes: n1:(1), n2(3), n3(0), n4(6) Items: f1:(7), f2:(2) i id+2 i succ Succ. Table i id+2 i succ Succ. Table i id+2 i succ Succ. Table 7 Items 1 i id+2 i succ Succ. Table

Lecture # Routing: Query Upon receiving a query for item id, a node Check whether stores the item locally If not, forwards the query to the largest node in its successor table that does not exceed id i id+2 i succ Succ. Table i id+2 i succ Succ. Table i id+2 i succ Succ. Table 7 Items 1 i id+2 i succ Succ. Table query(7)

Lecture # Overview Lookup Overview Hierarchical Lookup: DNS Routed Lookups  Chord  CAN

Lecture # CAN Associate to each node and item a unique id in an d- dimensional space  Virtual Cartesian coordinate space Entire space is partitioned amongst all the nodes  Every node “owns” a zone in the overall space Abstraction  Can store data at “points” in the space  Can route from one “point” to another Point = node that owns the enclosing zone Properties  Routing table size O(d)  Guarantees that a file is found in at most d*n 1/d steps, where n is the total number of nodes

Lecture # CAN E.g.: Two Dimensional Space Space divided between nodes All nodes cover the entire space Each node covers either a square or a rectangular area of ratios 1:2 or 2:1 Example:  Assume space size (8 x 8)  Node n1:(1, 2) first node that joins  cover the entire space n1

Lecture # CAN E.g.: Two Dimensional Space Node n2:(4, 2) joins  space is divided between n1 and n n1 n2

Lecture # CAN E.g.: Two Dimensional Space Node n2:(4, 2) joins  space is divided between n1 and n n1 n2 n3

Lecture # CAN E.g.: Two Dimensional Space Nodes n4:(5, 5) and n5:(6,6) join n1 n2 n3 n4 n5

Lecture # CAN E.g.: Two Dimensional Space Nodes: n1:(1, 2); n2:(4,2); n3:(3, 5); n4:(5,5);n5:(6,6) Items: f1:(2,3); f2:(5,1); f3:(2,1); f4:(7,5); n1 n2 n3 n4 n5 f1 f2 f3 f4

Lecture # CAN E.g.: Two Dimensional Space Each item is stored by the node who owns its mapping in the space n1 n2 n3 n4 n5 f1 f2 f3 f4

Lecture # CAN: Query Example Each node knows its neighbors in the d-space Forward query to the neighbor that is closest to the query id Example: assume n1 queries f n1 n2 n3 n4 n5 f1 f2 f3 f4

Lecture # Routing: Concerns Each hop in a routing-based lookup can be expensive  No correlation between neighbors and their location  A query can repeatedly jump from Europe to North America, though both the initiator and the node that store the item are in Europe!  Solutions: Tapestry takes care of this implicitly; CAN and Chord maintain multiple copies for each entry in their routing tables and choose the closest in terms of network distance What type of lookups?  Only exact match!  no beatles.*

Lecture # Summary The key challenge of building wide area P2P systems is a scalable and robust location service Solutions covered in this lecture  Naptser: centralized location service  Gnutella: broadcast-based decentralized location service  Freenet: intelligent-routing decentralized solution  DHTs: structured intelligent-routing decentralized solution

Lecture # Overview Centralized/Flooded Lookups

Lecture # Centralized: Napster Simple centralized scheme  motivated by ability to sell/control How to find a file:  On startup, client contacts central server and reports list of files  Query the index system  return a machine that stores the required file Ideally this is the closest/least-loaded machine  Fetch the file directly from peer

Lecture # Centralized: Napster Advantages:  Simple  Easy to implement sophisticated search engines on top of the index system Disadvantages:  Robustness, scalability  Easy to sue!

Lecture # Flooding: Gnutella On startup, client contacts any servent (server + client) in network  Servent interconnection used to forward control (queries, hits, etc) Idea: broadcast the request How to find a file:  Send request to all neighbors  Neighbors recursively forward the request  Eventually a machine that has the file receives the request, and it sends back the answer  Transfers are done with HTTP between peers

Lecture # Flooding: Gnutella Advantages:  Totally decentralized, highly robust Disadvantages:  Not scalable; the entire network can be swamped with request (to alleviate this problem, each request has a TTL)  Especially hard on slow clients At some point broadcast traffic on Gnutella exceeded 56kbps – what happened? Modem users were effectively cut off!

Lecture # Flooding: Gnutella Details Basic message header  Unique ID, TTL, Hops Message types  Ping – probes network for other servents  Pong – response to ping, contains IP addr, # of files, # of Kbytes shared  Query – search criteria + speed requirement of servent  QueryHit – successful response to Query, contains addr + port to transfer from, speed of servent, number of hits, hit results, servent ID  Push – request to servent ID to initiate connection, used to traverse firewalls Ping, Queries are flooded QueryHit, Pong, Push reverse path of previous message

Lecture # Flooding: Gnutella Example Assume: m1’s neighbors are m2 and m3; m3’s neighbors are m4 and m5;… A B C D E F m1 m2 m3 m4 m5 m6 E? E E E

Lecture # Flooding: FastTrack (aka Kazaa) Modifies the Gnutella protocol into two-level hierarchy  Hybrid of Gnutella and Napster Supernodes  Nodes that have better connection to Internet  Act as temporary indexing servers for other nodes  Help improve the stability of the network Standard nodes  Connect to supernodes and report list of files  Allows slower nodes to participate Search  Broadcast (Gnutella-style) search across supernodes Disadvantages  Kept a centralized registration  allowed for law suits 