Post on 18-Jan-2016
transcript
CS 268: Project Suggestions
Ion Stoica
January 26, 2004
istoica@cs.berkeley.edu 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
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”
istoica@cs.berkeley.edu 6
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
id Rtrigger
iddata
Receiver (R)
iddata
Rdata
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
Mobility
Host just needs to update its trigger as it moves from one subnet to another
Sender
Receiver(R1)
Receiver(R2)
id R1id R2
istoica@cs.berkeley.edu 9
iddata
Multicast
Receivers insert triggers with same identifier Can dynamically switch between multicast and unicast
Receiver (R1)id R1
Receiver (R2)
id R2
Sender
R1data
R2data
iddata
istoica@cs.berkeley.edu 10
Anycast
Use longest prefix matching instead of exact matching- Prefix p: anycast group identifier
- Suffix si: encode application semantics, e.g., location
Sender
Receiver (R1)p|s1 R1
Receiver (R2)p|s2 R2
p|s3 R3
Receiver (R3)
R1datap|adata p|adata
istoica@cs.berkeley.edu 11
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
SenderReceiver (R)
idT Tid R
Transcoder (T)
T,iddata
iddata
Rdata
idT,iddata idT,iddata
istoica@cs.berkeley.edu 12
Service Composition: Receiver Initiated
Receiver can also specify the operations to be performed on data
Receiver (R)
id idF,R
Firewall (F)
Sender idF F
idF,Rdata
Rdata
F,Rdata
iddata iddata
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
TCP
UDP
Run RRApplication level
congestion control
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
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
3
7
20
35
41
37 data
Chord circle
02m-1
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