CS 268: Project Suggestions

1. CS 268: Project Suggestions Ion Stoica January 26, 2004

2. Overview • Discuss 10 project suggestions • 5 related to i3 • 5 other projects • Legend: based on how well-defined projects are not necessary how difficult they are • Well-defined projects (5) • Less-defined project (3) • You need to define project’s goals (2) • Need to send me a one page proposal by Feb 8 istoica@cs.berkeley.edu

3. Project Related with Internet Indirection Infrastructure (i3) • Overview of i3 • Suggestion 1: Transcoding Application • Suggestion 2: Service Differentiation • Suggestion 3: Migrate-able End-to-End Protocols • Suggestion 4: Anonymous File Transfer • Suggestion 5: Event Notification System istoica@cs.berkeley.edu

4. Goal • Provide seamless support for basic communication abstractions • Multicast • Anycast • End-host mobility • Service composition istoica@cs.berkeley.edu

5. “Any problem in computer science can be solved by adding a layer of indirection” Key Observation • Many of current proposals use indirection, e.g., • Physical indirection point  mobile IP • Logical indirection point  IP multicast istoica@cs.berkeley.edu

6. trigger data data data id id R id R Internet Indirection Infrastructure (i3) • Each packet is associated an identifier id • To receive a packet with identifier id, receiver R maintains a trigger (id, R) into the overlay network Sender Receiver (R) istoica@cs.berkeley.edu

7. Service Model • API • sendPacket(p); • insertTrigger(t); • removeTrigger(t) // optional • Best-effort service model (like IP) • Triggers periodically refreshed by end-hosts • ID length: 256 bits istoica@cs.berkeley.edu

8. Receiver (R1) id id R1 R2 Receiver (R2) Mobility • Host just needs to update its trigger as it moves from one subnet to another Sender istoica@cs.berkeley.edu

9. data data data data R1 R2 id id Multicast • Receivers insert triggers with same identifier • Can dynamically switch between multicast and unicast id R1 Receiver (R1) Sender id R2 Receiver (R2) istoica@cs.berkeley.edu

10. p|a data p|a data data R1 Anycast • Use longest prefix matching instead of exact matching • Prefix p: anycast group identifier • Suffix si: encode application semantics, e.g., location Receiver (R1) R1 p|s1 R2 p|s2 Sender Receiver (R2) R3 p|s3 Receiver (R3) istoica@cs.berkeley.edu

11. idT,id T,id data data data data id R idT,id data Service Composition: Sender Initiated • Use a stack of IDs to encode sequence of operations to be performed on data path • Advantages • Don’t need to configure path • Load balancing and robustness easy to achieve Transcoder (T) Receiver (R) Sender id R T idT istoica@cs.berkeley.edu

12. id data idF,R F,R id data data data data R Service Composition: Receiver Initiated • Receiver can also specify the operations to be performed on data Firewall (F) Receiver (R) F Sender idF id idF,R istoica@cs.berkeley.edu

13. Suggestion 1: Transcoding Application • Design a transcoding application • From one video format to another (e.g., MPEG  H.263) • From one data format to another (e.g., HTML  WML) • Transparent recovery • When one transcoder fails, another one takes over without end-hosts being involved istoica@cs.berkeley.edu

14. Suggestion 2: Service Differentiation • Problem: flow isolation (UDP can kill TCP) • Solution outline: TCP UDP Application level congestion control Run RR TCP UDP istoica@cs.berkeley.edu

15. Suggestion 3: Migrate-able End-to-End Protocols • Design a congestion control mechanism (e.g. TCP) such that it is possible to change the receiving machine in the middle of the transfer! • A and B open a connection (A receiver; B source) • A changes to A’ • B continues to send data to A’ without creating a new connection • Challenge: transparently transfer the receiver state from A to A’ istoica@cs.berkeley.edu

16. Suggestion 4: Anonymous File Sharing • IDs may be chosen such that not to reveal end-host identity • E.g., pick random IDs • Sender doesn’t know the IP address of receiver • You can simply use web to share files! • Questions: • Anonymous search engine • Anonymity vs. performance istoica@cs.berkeley.edu

17. Suggestion 5: Event Notification System • Users specify events in which they are interested as a conjunction of attributes, e.g., • (stock=“msr”) and (share_price > 60) • (source=“Berkeley”) and (destination=“North Lake Tahoe”) and (time < 3.5 hours) • Create an efficient delivery tree • Users with the same interest grouped under the same tree • Users in the same geographic region grouped under the same tree • Note: i3 not general enough to address this problem istoica@cs.berkeley.edu

18. DHTs Overview • Each data item and machine (node) in the system has associated a unique ID in a large ID space • Hash table like interface • put(id, data) • data = get(id) • ID space is partitioned among nodes • Data items are stored at the node responsible for its ID istoica@cs.berkeley.edu

19. 37 data Example: Chord • Circular ID space [0..2m-1] • Consider two consecutive nodes on the ID circle with IDs N1 and N2, where N2 follows N1 • Then node N2 is responsible for interval (N1, N2] • Node 35 inserts (37, data) • Node 3 query data with ID 37 0 2m-1 3 7 Chord circle 41 20 35 istoica@cs.berkeley.edu

20. Suggestion 6: Location Control in DHTs • Users do not have control over where data items are located • Advantages: • Users don’t need to know about individual nodes • System can recover in case of failure without user involvement • Disadvantages: • Not efficient • Enforces uniform trust model • Challenge: design a system in which users have “some” degree of control on where data items are located • E.g., “I want my items to be located only on nodes in US” istoica@cs.berkeley.edu

21. Suggestion 7: Reduce (eliminate) Multicast State • In IP Multicast each router maintains state for each multicast group that has traffic traversing it • Problem: state hard to maintain and manage • Extreme solution: maintain all receiver addresses in each packet • Routers don’t need to maintain any state, but • Packet headers can become very large  huge overhead • Solution: design an algorithm in between • Maintain some state in routers and some in packets • Note: you can think either at the IP or application layer istoica@cs.berkeley.edu

22. Suggestion 8: Multipath Transport Protocols(due to Kevin Lai) • Motivation • Many paths between host A and B in current Internet (multiple base stations, multihoming) • Don’t know characteristics of paths • Which one to use? • Use all of them • Must do so with congestion control • For n independent paths, get n speedup ? istoica@cs.berkeley.edu

23. Suggestions 9: Overlay Routing • Assume • A network topology T • A routing algorithm running on top of T • You control a fraction f of nodes in T • Question: • How well can you approximate an “arbitrary” routing metric as a function of f and topology T ? • Example: • T uses # of hops to implement shortest path • You know delay distributions along links in T • How well can you approximate lowest latency routing metric assuming a power-law topology and f = 10%? istoica@cs.berkeley.edu

24. Suggestion 10: Forwarding in Low Energy Wireless Networks • Assumptions • Each node is independently switching between ON and OFF states • Two nodes can communicate only when both of them are simultaneously ON • A node stores a packet in transit until it finds the next hop ON • Routing tables are known • Question: • What is the relationship between the fraction of time a node is ON and the time to deliver a message and the amount of storage required by a node? istoica@cs.berkeley.edu

25. Next Step • You can either choose one of the projects we discussed during this lecture, or come up with your own • Pick your partner, and submit a one page proposal by February 8. The proposal needs to contain: • The problem you are solving • Your plan of attack with milestones and dates • Any special resources you may need istoica@cs.berkeley.edu