Tussle in Cyberspace: Defining Tomorrow’s Internet Presented by: Khoa To

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

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.

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

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.

Conflicts Illustrations: and Principle Applications

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

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.

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

How about the old principles?

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)

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.

Policy-free mechanism  Policy-free mechanisms – Still biased – Hard to design value-neutral mechanisms  Should design to isolate policies that generate conflicts

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.