Tussle in Cyberspace: Defining Tomorrows Internet

1
Tussle in CyberspaceDefining Tomorrows Internet

• David D.clark, John Wroclawski
• Karen R.Sollins, Robert Braden
• 20023146 Jonghwan Kim
• shine_at_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
• gt 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.
• Dont 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
• gtThese can be examined with implications for
  research and network design principles.

12
3.2 Trust

• Many of users in the Internet dont trust each
  other.
• They would like protection from system
  penetration attacks,DoS attacks, etc.
• gtUsers 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 dont trust many of the parties they
  actually want to talk to.
• Users less and less trust the software they have
  to run.
• gtWe 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.
• gtWe 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 todays 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.
• gt 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?