Tussle in Cyberspace: Defining Tomorrow’s Internet

1. Tussle in Cyberspace:Defining Tomorrow’sInternet Presented by: Khoa To

2. Problem with the Internet • Created by assumptions of cooperation • Abused by some to wreck havocs & to make personal gain. • Modified by the rest to protect themselves & be competitive • Modified by administrators to enforce rules • Modified by users to bypass the rules • Results: • Principle designs are violated • Performance becomes sub-optimal

3. What this paper offers • If you are designing something new, here are some guiding principles: • Anticipate conflicts so that they happen within the design boundary • Outcome is a function of the environment & its conflicts, not pre-defined.

4. How to design • Localize the effects of conflicts by containing them within modules. • DNS does not localize effects of conflicts • QoS localizes conflicts • Allow users to configure their preferences • Users should have choices to improve robustness and foster competitions & innovations • Choices also offer more well-defined interfaces

5. Implications • Some conflicts can be resolved by compromises • Design has to facilitate compromises • Conflicts are dynamic and evolve • Design has to anticipate this dynamics. • Don’t design an answer, design a playing field that facilitates a solution. • Your playing field is always influenced by the solution you have in mind. Try to minimize it. • Visibility of user preferences affect their behaviors.

6. Conflicts Illustrations: and Principle Applications

7. The Economic Conflicts • Users compete for economic gains. • Providers compete for customers • Customers demand cheaper prices. • Design choices to facilitate choices • Easy for customers to switch providers • Easy for providers to offer choices. • Examples: • Address allocations & designations. • Price differentiations • Access to the wire • Users choice of providers for different activities • Facilitate payments

8. The Trust Issue • Design choices for users to “configure” trusts: • How much to reveal my identity • Which anonymous users do I want to talk to. • Do I, or my network administrators, dictate this. • Design choices for isolating conflicts • Separate trust issues from other configurations • Identify different trust issues • Design to encourage responsibilities • Design a playing field to penalize negative anonymous actions & reward positive behaviors.

9. The problems with openness • Openness leads to innovation • Certain optimization reduces openness • Design to isolate openness from optimization • Ex: Vertical integration should not affect openness

10. How about the old principles?

11. End-to-end arguments • Innovation • Network can accommodate many new applications • Reliability and robustness • Bring points of failure to the end points. • But end-to-end design is eroding!! • Need to redefine some of the network features (what end-to-end & transparency mean)

12. Remaking playing fields to support end-to-end argument • Anticipate the evolution of applications • Give applications enough power to retrieve necessary information from the network so they don’t have to be implemented inside the network. • Influence the evolution of applications • Isolate conflicts from the network transparency • Anticipate failure of transparency • Design to discourage transparency impairment • Design the playing field for privacy vs. transparency • Force privacy decisions to be public and visible.

13. Policy-free mechanism • Policy-free mechanisms • Still biased • Hard to design value-neutral mechanisms • Should design to isolate policies that generate conflicts

14. In conclusion … • How to design a system that allows conflicts to exists without violating principles? • Design a playing field that facilitates conflict resolutions. • Design with flexibility so users can specify their preferences.