Tussle in Cyberspace: Defining Tomorrow’s Internet

1. Tussle in Cyberspace:Defining Tomorrow’s Internet David D.clark, John Wroclawski Karen R.Sollins, Robert Braden 20023146 Jonghwan Kim shine@cnlab.kaist.ac.kr

2. Abstract • This paper explores important reality that surrounds the Internet today. • We discuss some examples of tussle, and offer some technical design principles that take it into accound.

3. 1.Introduction • There are many players that make up the Internet milieu with interests directly at odds with each other. • E.g. Music lovers who wants to exchange mp3 VS the rights holders who want to stop it.

4. 1.1 The natures of engineering and society • Engineers attempt to solve problems by designing mechanisms with predictable consequences. • The operation of societies have the dynamic management of evolving and coflicting interests. • Tussle – regulated by mechanisms such as laws,judges,and the like. • Technical architecture must accommodate the tussles of society,while continuing to achive its traditional goals.

5. 1.2 The Internet landscape • Users, who run applications over the Internet • Commercial ISPs, who sell Internet for profit. • Private sector network providers • Governments • Intellectual property rights holders • Providers of contents and services => They makes tussles in Cyberspace

6. 2.Principles • Designs that permit variation will flex under pressure and survive. • Modularize the design along tussle boundaries. • Design for choice, to permit the different players to express their preferences.

7. 2.1 Modularize along tussle boundaries • Functions that are within a tussle space should be logically separated. • Solutions that are less efficient from a technical perspective may do a better modularity.

8. 2.2 Design for choice • Network protocols must permit all the parties to express their own choice.

9. 2.3 Implications(design issue) • Choice often requires open interfaces. • Tussles often happen across interfaces. • It matters if the consequence of choice is visible. • Tussles have different flavors. • Tussles evolve over time. • There is no such thing as value-neutal design. • Don’t assume that you design the answer.

10. 3.Tussle spaces • 3.1 Economics • 3.2 Trust • 3.3 The tussles of openness

11. 3.1 Economics • Providers tussle as they compete, and consumers tussle with providers to get the service they want at a low price. • Examples, • Provider lock-in from IP addressing. • Value pricing. • Residential broadband access. • Competitive wide area access =>These can be examined with implications for research and network design principles.

12. 3.2 Trust • Many of users in the Internet don’t trust each other. • They would like protection from system penetration attacks,DoS attacks, etc. =>Users should be able to choose with whom they interact and the level of transparency they offer to other users. -- by the principle of “design for choice”

13. 3.2 Trust(continue) • Most users don’t trust many of the parties they actually want to talk to. • Users less and less trust the software they have to run. =>We can defend on third parties or regulation,public opinion and so on.

14. 3.3 The tussles of openness • The openness to innovation has perhaps been the most critical success factor for the Internet. • But ISPs dislike and fear the openness. =>We can exercise to speculate about whether openness tussles can be modularized,and what this means for mechanism design.

15. 4.Revisiting old principle • 4.1 The future of the end to end arguments. • 4.2 Separation of policy and mechanism.

16. 4.1 The future of the end to end arguments • End to end argument is the most respected Internet design principle. • End to end argument state that mechanism should not be placed in the network if it can be placed at the end node.

17. 4.1 The future of the end to end arguments(continue) • End to end arguments are still valid,but need a more complex articulation in today’s world. • Evolution and “enhancement” of existing,mature application is inevitable. • The most we can do to protect maturing application is to bias the tussle. • Keeping the net open and transparent for new applications is the most important goal. • Failures of transparency will occur-design what happens then. • Peeking is irresistible.

18. 4.2 Separation of policy and mechanism • The chief advantage of attempting to separate mechanism and policy is to isolate some regions of the system from tussle. • Technologists should design policy-free mechanism,and allow those who use the system to adjust the mechanisms to match their specific needs.

19. 5. Lesson for designers • ISPs do not invest money without guarantee of increased revenues • Failure to deploy multicast. • Failure to deploy QoS. => One can from the past. • Protocol design,by creating opportunities for competition,can impose a direction on evolution.

20. 6. Conclusion • We,as techinical designers,should not try to deny the reality of the tussle,but instead recognize our power to shape it.

21. The end • Thank you! • Any questions and comments?