Tussle in cyberspace:
Defining tomorrow’s internet
D.Clark, J.Wroclawski, K.Sollins & R.Braden
Presented by: Ao-Jan Su
(Slides in courtesy of: Baoning Wu)
Introduction
• Different Internet holders have interests that
may be adverse to each other, and they vie to
favor their particular interests.
• This is called TUSSLE.
• Accommodating this tussle is crucial to the
evolution of the network’s technical architecture.
Tussle Examples
• The different players
–Music lovers vs. the rights holders
–People who want to talk in private vs. the
government that want to tap their conversation
–ISPs must interconnect but are sometimes fierce
competitors
• New requirements on the internet’s technical
architecture
–Motivate new design strategies to accommodate the
growing tussle
Structure of this paper
• Difference between the mechanisms and
society.
• Outline some proposed design principles
• Discussion of some tussle space
Natures of engineering and society
• Engineers: solve the problems by designing
mechanisms with predictable consequences.
• Society: dynamic management of evolving and
conflicting interests.
• My experience
Internet landscape
•
•
•
•
•
•
Users
Commercial ISPs
Private sector network providers
Governments
Intellectual property rights holders
Content providers and higher level services
Principles
• Highest-level: design for variation in outcome
-- Be flexible
• Two specific principles:
• Modularize the design along tussle boundaries
• Use modularity to manage complexity
• Design for choice
• Users’ choice of mail systems
Implications from principles
• Choice often requires open interfaces
• Allow competition among algorithms
• Tussles often happen across interfaces
• Example: BGP connects competitive ISPs
• It matters if the consequence of choice is visible
• Public vs. secret (routing arrangement among ISPs)
• Tussles have different flavors
• Different interests (sender & traffic carrier)  pricing
problem
Implications from principles (Cont.)
• Tussles evolve over time
• It is a multi-round game
• No such thing as value-neutral design
• No perfect design decisions.
• Don’t assume that you design the answer
• You are designing a playing field, not the outcome.
Tussle spaces (1)
• Economics
• Providers tussles as they compete and consumers
tussle with providers to get the service they want at
a low price
• Our principle of design of choice into mechanism is
the building block of competition
• Customers must have the ability to choose (switch)
providers freely.
Examples
• Provider lock-in from IP addressing
• Incorporate mechanisms that make it easy for a
host to change address
• Change you cell phone carrier without changing
your cell phone number
• Value pricing
• Divide customers based on their willingness to pay
• Pay higher rate to run a server at home
Examples (continue)
• Residential broadband access
• Municipal deployment of fiber as a platform for
competitors
• Competitive wide area access
• Support source routing with a recognition of the
need for payment
• Pay toll
Tussle spaces (2)
• Trust
• Users do not trust each other.
• Users don’t trust parties they actually want to talk to
• Less and less trust to their own software
• “Not permitted is forbidden” or “Not forbidden
is permitted”
• Design for choice: privacy vs. security
Tussle space (3)
• Openness
• The openness to innovation that permits a new
application to be deployed
• Vertical integration
• Are you willing to pay more for ISPs with QoS?
Old principles
• End to end arguments
• Still valid, but need a more complex articulation
• Network could provide more information (ECN, QoS)
• Separation of policy and mechanism
• Mechanism defines the range of “policies”
• No pure separation of policy from mechanism.
Conclusion
• Do not deny the reality of the tussle, but
recognize our power to shape it.
Questions?