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?