|
|
|
David Wetherall |
|
University of Washington |
|
|
|
With thanks to David Tennenhouse, John Guttag,
Steve Garland, Ulana Legedza, Erik Nygren, and members of the MIT SDS group. |
|
|
|
|
Active networks |
|
ANTS, our active network system |
|
Lessons Learned |
|
|
|
|
|
Network change is excruciatingly slow |
|
Widespread consensus, manual deployment |
|
Consider: |
|
Congestion (RED ‘93); More Addresses (IPv6 ‘91) |
|
Security (IPSEC ‘93); Multi-point (IP multicast
‘90) |
|
Contrast: |
|
Web (‘93); Quake (‘96); Instant Messaging (‘98) |
|
|
|
|
|
|
|
Apply mobile code! |
|
Ease deployment; accelerate pace of innovation |
|
|
|
|
|
|
|
|
|
|
Goal: Let each user control their packets |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Nodes provide API for new service code |
|
Soft-storage, routing, environment queries,
packet manipulation |
|
Nodes run service code safely |
|
Protect state at node; enforce packet invariants |
|
Nodes manage local resources |
|
Bound code runtimes and other resources |
|
|
|
|
|
Tie code distribution to packet forwarding |
|
End-systems pre-load code, active nodes load
hop-by-hop as needed and then cache |
|
|
|
|
|
|
|
|
|
|
|
|
|
Reference is based on fingerprint |
|
Efficient: MD5 is 128 bits, quick to compute |
|
Prevents code spoofing: verify without trust |
|
No need for standards body: distributed naming |
|
|
|
|
|
User-level reference platform |
|
~10,000 lines, 100% Java, UDP overlay |
|
Nodes build on Java protection |
|
|
|
Publicly released for two years |
|
http://www.cs.washington.edu/homes/djw/ants/ |
|
Used at MIT, Utah, TIS, TASC, SRI, UIUC, UCLA, … |
|
|
|
|
|
Interested in three dimensions: |
|
Applications |
|
Performance |
|
Security and Resource Management |
|
|
|
|
|
|
Q: Can we deploy important services? |
|
Chosen approach lets users select independently |
|
Programs constrained by active nodes |
|
|
|
A: Yes. |
|
Well-suited to experimenting w/ protocol
variations (rather than computation pushed into network) |
|
Exceptions: enforcing policy at a point
(firewalls) and resource control (guaranteed service) |
|
|
|
|
|
|
|
|
Auctions |
|
Web cache diversion routing |
|
“TCP-SYN” filtering |
|
Reliable Multicast support |
|
Multicast (single source, PIM) |
|
Mobility |
|
Path MTU discovery |
|
|
|
|
|
|
Q: Is performance a show-stopper? |
|
Model is more expensive than IP |
|
|
|
A: No. |
|
Very few extra steps over IP in common case and
extra steps (demux, safe eval) known to run fast |
|
Balance available vs. required computation |
|
e.g. 1GHz, 1Gbps, 1000b, 100% à 1000 cycles |
|
|
|
|
|
|
|
|
Q: Can untrusted users program the network? |
|
Need to isolate services and protect network |
|
|
|
A: Partly. This is difficult! |
|
Requires Protection |
|
My program can’t corrupt your program à Solved |
|
Requires Resource Management |
|
My program can’t starve yours à Not solved |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
How should we prevent this? |
|
TTLs are a weak solution; not related to
topology |
|
Fairness mechanisms mitigate, but not enough |
|
ANTS falls back on certification of programs … |
|
|
|
|
There are important applications |
|
Performance is not the limiting factor |
|
Protection is not the limiting factor |
|
Resource Management remains problematic |
|
Notes