tussle in cyberspace defining tomorrow s internet l.
Skip this Video
Loading SlideShow in 5 Seconds..
PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 21

- PowerPoint PPT Presentation

  • Uploaded on

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 Abstract This paper explores important reality that surrounds the Internet today.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about '' - paul

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
tussle in cyberspace defining tomorrow s internet

Tussle in Cyberspace:Defining Tomorrow’s Internet

David D.clark, John Wroclawski

Karen R.Sollins, Robert Braden

20023146 Jonghwan Kim


  • 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.
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.
1 1 the natures of engineering and society
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.
1 2 the internet landscape
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

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.
2 1 modularize along tussle boundaries
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.
2 2 design for choice
2.2 Design for choice
  • Network protocols must permit all the parties to express their own choice.
2 3 implications design issue
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.
3 tussle spaces
3.Tussle spaces
  • 3.1 Economics
  • 3.2 Trust
  • 3.3 The tussles of openness
3 1 economics
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.

3 2 trust
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”

3 2 trust continue
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.

3 3 the tussles of openness
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.

4 revisiting old principle
4.Revisiting old principle
  • 4.1 The future of the end to end arguments.
  • 4.2 Separation of policy and mechanism.
4 1 the future of the end to end arguments
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.
4 1 the future of the end to end arguments continue
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.
4 2 separation of policy and mechanism
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.
5 lesson for designers
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.
6 conclusion
6. Conclusion
  • We,as techinical designers,should not try to deny the reality of the tussle,but instead recognize our power to shape it.
the end
The end
  • Thank you!
  • Any questions and comments?