1. 3-1 Distributed Hash Tables CS653, Fall 2010

2. 3-2 Implementing insert/retrieve: distributed hash table (DHT) r Hash table m data structure that maps “keys” to “values” m essential building block in software systems r Distributed Hash Table (DHT) similar, but spread across the Internet r DHT Interface: m insert(key, value) m lookup(key) r DHT: overlay (on top of internet) of nodes m each DHT node supports single operation: m given input key, route messages toward node holding key

3. 3-3 K V DHT in action

4. 3-4 K V DHT in action

5. 3-5 K V DHT in action Operation: take key as input; route messages to node holding key

6. 3-6 DHT in action: insert() K V insert(K 1,V 1 ) Operation: take key as input; route messages to node holding key

7. 3-7 K V DHT in action: insert() insert(K 1,V 1 ) Operation: take key as input; route messages to node holding key

8. 3-8 (K 1,V 1 ) K V DHT in action: insert() Operation: take key as input; route messages to node holding key

9. 3-9 lookup (K 1 ) K V DHT in action: lookup() Operation: take key as input; route messages to node holding key

10. DHT Design Goals r An “overlay” network with: m flexible mapping of keys to physical nodes m small network diameter m small degree m local routing decisions r A “storage” or “memory” mechanism with m best-effort persistence (soft state)

11. 3-11 Example DHT: Chord r Each key, k, maps to node on ring m # key values may be > # nodes m key k maps to node on ring with next largest id: successor (k) r m-bit identifier space: 2 m ids r Identifiers ordered on identifier ring (Chord ring) modulo 2 m Example: 10 node Chord with m=6 storing 5 keys.

12. 3-12 Basic lookup Lookup: r node i forwards to node i+1, until node holding k is reached r memory; O(1), each node need only know one neighbor r routing time: O(N)

13. 3-13 Accelerating Lookups r Lookups accelerated by maintaining additional routing information r Each node maintains a routing table with (at most) m entries (where N=2 m ) called finger table r i th entry in table at node n contains identity of first node, s, that succeeds n by at least 2 i-1 on chord r s = successor(n + 2 i-1 ) (all arithmetic mod 2)

14. 3-14 Routing by halving distance  Node uses finger tables to halve the ID space distance to destination in each step

15. 3-15 Churn r Churn: nodes join, leave system m stored keys must be move to (on leave) or moved from (join) neighboring nodes m finger tables must be updated m too much churn: too much overhead r Joins: Node n joins by asking any node m for n’s successor r Voluntary leaves m Transfer keys to successor, notify predecessor r Failure handling: maintain r backup successors m r tuned to the mean-time-to-failure of nodes

16. 3-16 DHTs discussion r What systems can you build using DHTs? r How to reduce stretch? [Plaxton97] r How to support range requests or partial matches between request and key? r What real applications use DHTs today? m Why or why not? r Pros and cons of a centralized index?

17. 3-17 Indirection

18. 3-18 Indirection Indirection: rather than reference an entity directly, reference it (“indirectly) via another entity, which in turn can or will access the original entity " Every problem in computer science can be solved by adding another level of indirection" -- Butler Lampson A B x

19. 3-19 Multicast: one sender to many receivers r Multicast: act of sending datagram to multiple receivers with single “transmit” operation r Question: how to achieve multicast Network multicast r router actively participate in multicast, making copies of packets as needed and forwarding towards multicast receivers Multicast routers (red) duplicate and forward multicast datagrams

20. 3-20 Internet Multicast Service Model multicast group concept: use of indirection m host addresses IP datagram to multicast group m routers forward multicast datagrams to hosts that have “joined” that multicast group 128.119.40.186 128.59.16.12 128.34.108.63 128.34.108.60 multicast group 226.17.30.197

21. 3-21 Multicast via Indirection: why? r Naming and forwarding in IP tailored for point-to-point communication r Indirection m Provides flexible naming m Decouples sender from receivers (and their joins and leaves)

22. 3-22 How do you contact a mobile friend? r search all phone books? r call her parents? r expect her to let you know where he/she is? I wonder where Alice moved to? Consider friend frequently changing addresses, how do you find her? Mobility and Indirection

23. 3-23 Mobility and indirection: r mobile node moves from network to network r correspondents want to send packets to mobile node r two approaches: m indirect routing: communication from correspondent to mobile goes through home agent, then forwarded to remote m direct routing: correspondent gets foreign address of mobile, sends directly to mobile

24. 3-24 Mobility: Vocabulary home network: permanent “home” of mobile (e.g., 128.119.40/24) permanent address: address in home network, can always be used to reach mobile e.g., 128.119.40.186 home agent: entity that will perform mobility functions on behalf of mobile, when mobile is remote wide area network

25. 3-25 Mobility: more vocabulary care-of-address: address in visited network. (e.g., 79,129.13.2) wide area network visited network: network in which mobile currently resides (e.g., 79.129.13/24) permanent address: remains constant ( e.g., 128.119.40.186) foreign agent: entity in visited network that performs mobility functions on behalf of mobile. correspondent: wants to communicate with mobile

26. 3-26 Mobility: registration End result: r foreign agent knows about mobile r home agent knows location of mobile wide area network home network visited network 1 mobile contacts foreign agent on entering visited network 2 foreign agent contacts home agent home: “this mobile is resident in my network”

27. 3-27 Mobility via Indirect Routing wide area network home network visited network 3 2 4 1 correspondent addresses packets using home address of mobile home agent intercepts packets, forwards to foreign agent foreign agent receives packets, forwards to mobile mobile replies directly to correspondent

28. 3-28 Indirect Routing: comments r mobile uses two addresses: m permanent address: used by correspondent (hence mobile location is transparent to correspondent) m care-of-address: used by home agent to forward datagrams to mobile r foreign agent functions may be done by mobile itself r triangle routing: correspondent-home-network- mobile m inefficient when correspondent, mobile are in same network

29. 3-29 Indirect Routing: moving between networks r suppose mobile user moves to another network m registers with new foreign agent m new foreign agent registers with home agent m home agent updates care-of-address for mobile m packets continue to be forwarded to mobile (but with new care-of-address) r mobility, changing foreign networks transparent: ongoing connections can be maintained!

30. 3-30 Mobility via Direct Routing wide area network home network visited network 4 2 5 1 correspondent requests, receives foreign address of mobile correspondent forwards to foreign agent foreign agent receives packets, forwards to mobile mobile replies directly to correspondent 3

31. 3-31 Mobility via Direct Routing: comments r overcomes triangle routing problem r non-transparent to correspondent: correspondent must get care-of-address from home agent m what happens if mobile changes networks?

32. 3-32 Mobile IP r RFC 3220 r Has many features we’ve seen: m home agents, foreign agents, foreign-agent registration, care-of-addresses, encapsulation (packet-within-a-packet) r Three components to standard: m agent discovery m registration with home agent m indirect routing of datagrams

33. 3-33 Mobility via indirection: why indirection? r Transparency to correspondent r “Mostly” transparent to mobile (except mobile must register with foreign agent) m transparent to routers, rest of infrastructure m practical concern: if egress filtering is in place in foreign networks (since source IP address of mobile is its home address): spoofing?

34. 3-34 An Internet Indirection Infrastructure Motivation : r Today’s Internet is built around point-to-point communication abstraction: m send packet “p” from host “A” to host “B” m one sender, one receiver, at fixed and well- known locations r … not appropriate for applications that require other communications primitives: m multicast (one to many) m mobility (one to anywhere) m anycast (one to any) r We’ve seen indirection used to provide these services m idea: make indirection a “first-class object”

35. 3-35 Internet Indirection Infrastructure (i3) r Change communication abstraction: instead of point-to-point, exchange packets by name m each packet has an identifier ID m to receive packet with identifier ID, receiver R stores trigger (ID, R) in network m triggers stored in network overlay nodes SenderReceiver (R) IDR trigger send(ID, data) send(R, data)

36. 3-36 Service Model r API  sendPacket( p );  insertTrigger( t );  removeTrigger( t ); // optional r Best-effort service model (like IP) r Triggers periodically refreshed by end-hosts m Q: what is this approach called? r Reliability, congestion control, flow-control implemented at end hosts, and trigger-storing overlay nodes packet p: (ID,data) trigger t: (ID, addr)

37. 3-37 Discussion r Trigger is similar to routing table entry r Essentially: application layer publish-subscribe infrastructure r Unlike IP, end hosts control triggers, i.e., end hosts responsible for setting and maintaining “routing tables” r Provide support for m mobility m multicast m anycast m composable services

38. 3-38 Mobility r Receiver updates its trigger as it moves from one subnet to another m mobility transparent to sender m location privacy Sender Receiver (R1) IDR1 send(ID,data) send(R1, data) trigger

39. 3-39 Mobility r Receiver updates its trigger as it moves from one subnet to another m mobility transparent to sender m location privacy Sender IDR2 send(ID,data) Receiver (R2) send(R2, data) (new) trigger

40. 3-40 Multicast r Unifies multicast and unicast abstractions m multicast: receivers insert triggers with same ID r Application naturally moves between multicast and unicast, as needed m “impossible” in current IP model Sender Receiver (R1)IDR1 send(ID,data) send(R1, data) Receiver (R2) IDR2 send(R2, data)

41. 3-41 Anycast (cont’d) r Route to any one in set of receivers  Receiver i in anycast group inserts same ID, with anycast qualifications r Route to receiver with best match between a and s i Sender Receiver (R1) ID|s 1 R1 send(ID|a,data) Receiver (R2) ID|s 2 R2 ID|s 3 R3 Receiver (R3) send(R1,data)

42. 3-42 Composable Services r Use stack of IDs to encode successive operations to be performed on data (e.g., transcoding) r Don’t need to configure path between services Sender (MPEG) Receiver R (JPEG) ID_ MPEG/JPEG S_ MPEG/JPEG ID R send((ID_ MPEG/JPEG,ID), data) S_ MPEG/JPEG send(ID, data) send(R, data)

43. 3-43 Composable Services (cont’d) r Both receivers and senders can specify operations to be performed on data Receiver R (JPEG) ID_ MPEG/JPEG S_ MPEG/JPEG ID (ID_ MPEG/JPEG, R) send(ID, data) S_ MPEG/JPEG Sender (MPEG) send((ID _MPEG/JPEG, R), data) send(R, data)

44. 3-44 Heterogeneous Multicast r Both receivers and senders can specify operations to be performed on data Receiver R1 (JPEG) ID_ MPEG/JPEG S_ MPEG/JPEG ID (ID_ MPEG/JPEG, R1) send(ID, data) S_ MPEG/JPEG Sender (MPEG) send((ID _MPEG/JPEG, R1), data) send(R1, data) Receiver R2 (JPEG) ID R2 send(R2, data)

45. 3-45 Discussion of I3 r How would receiver signal ACK to sender? what is needed? r Does many-to-one fit well in this paradigm? r Security, snooping, information gathering: what are the issues? r In-network storage to handle disconnection?

46. 3-46 Indirection: Summary We’ve seen indirection used in many ways: r multicast r mobility r Internet indirection Uses of indirection: r sender does not need to know receiver id - do not want sender to know intermediary identities r elegant r transparency of indirection is important r performance: is it more efficient? r security: important open issue for I3