Docstoc

The Internet Past_ Present_ and Future

Document Sample
The Internet Past_ Present_ and Future Powered By Docstoc
					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.

   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
   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
 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
   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
   Network protocols must permit all the
    parties to express their own choice.
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.1 Economics
   3.2 Trust
   3.3 The tussles of openness
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
   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)
   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
   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.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
   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)
   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
   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
   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

   We,as techinical designers,should not
    try to deny the reality of the tussle,but
    instead recognize our power to shape it.
The end
   Thank you!
   Any questions and comments?

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:7
posted:3/21/2012
language:
pages:21