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

2. istoica@cs.berkeley.edu2 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

3. istoica@cs.berkeley.edu3 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

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

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

6. istoica@cs.berkeley.edu6 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 idR trigger iddata Receiver (R) iddata R

7. istoica@cs.berkeley.edu7 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

8. istoica@cs.berkeley.edu8 Mobility  Host just needs to update its trigger as it moves from one subnet to another Sender Receiver (R1) Receiver (R2) idR1 idR2

9. istoica@cs.berkeley.edu9 iddata Multicast  Receivers insert triggers with same identifier  Can dynamically switch between multicast and unicast Receiver (R1) idR1 Receiver (R2) idR2 Sender R1data R2data iddata

10. istoica@cs.berkeley.edu10 Anycast  Use longest prefix matching instead of exact matching -Prefix p: anycast group identifier -Suffix s i : encode application semantics, e.g., location Sender Receiver (R1) p|s 1 R1 Receiver (R2) p|s 2 R2 p|s 3 R3 Receiver (R3) R1 data p|a data p|a data

11. istoica@cs.berkeley.edu11 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 Sender Receiver (R) id T T id R Transcoder (T) T,id data iddata R id T,id data id T,id data

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

13. istoica@cs.berkeley.edu13 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

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

15. istoica@cs.berkeley.edu15 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’

16. istoica@cs.berkeley.edu16 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

17. istoica@cs.berkeley.edu17 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

18. istoica@cs.berkeley.edu18 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

19. istoica@cs.berkeley.edu19 Example: Chord  Circular ID space [0..2 m -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 3 7 20 35 41 37data Chord circle 0 2 m -1

20. istoica@cs.berkeley.edu20 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”

21. istoica@cs.berkeley.edu21 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

22. istoica@cs.berkeley.edu22 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 ?

23. istoica@cs.berkeley.edu23 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%?

24. istoica@cs.berkeley.edu24 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?

25. istoica@cs.berkeley.edu25 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