Tussle in cyberspace: Defining tomorrow`s internet (2002)

Download Report

Transcript Tussle in cyberspace: Defining tomorrow`s internet (2002)

Tussle in cyberspace:
Defining tomorrow’s internet
(2002)
D.Clark, J. Wroclawski, K. Sollins & R. Braden
Presented by: Gergely Biczok
(Slides in courtesy of: Ao-Jan Su)
Introduction



Different Internet players 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 spaces
Natures of engineering and
society

Engineers: solve the problems by designing
mechanisms with predictable consequences.

Society: dynamic management of evolving
and conflicting interests.

Personal example: Network Neutrality
Measurement project
Internet players

Users


Commercial ISPs





You and me
AT&T, Comcast
Private sector network providers
Governments
Intellectual property rights holders
Content providers and higher level services

Google, Amzaon, Ebay
Principles

Highest-level: design for variations in outcome



Be flexible
Tussle in the design, not by violating the design
Two specific principles:


Modularize the design along tussle boundaries
 Use modularity to manage complexity
 Like reusable software components
Design for choice
 Users’ choice of mail systems
 ISPs has a different view (filtering/redirecting port 25)
Implications from principles

Choice often requires open interfaces


Tussles often happen across interfaces


Example: BGP connects competitive ISPs
It matters if the consequence of choice is visible



Allow competition among algorithms
Public vs. secret (routing arrangement among ISPs)
2007: Comcast’s choice of poisoning BitTorrent (loss of
prestige)
Tussles have different flavors


Not certainly adverse interests, but
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


1. 2005: BitTorrent got filtered
2. 2006: Encryption implemented
3. 2007: Updated filters: based on flow-patterns and peer-tracker
communication
4. 2008: TCP-over-UDP, dropping RST, VPNs
5. …
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
Since 2002: 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
Since 2002
 research on Internet economics shows interest of T1 ISPs
contact end-users directly (larger revenue)
 Network Anti-Neutrality: ISPs want to milk content providers
Tussle spaces (2)

Trust




Users do not trust each other
Users don’t trust parties they actually want to talk to
 Explicit choice of trusted 3rd party
Less and less trust to their own software
 Non-technical solution seems feasible
Design for choice: privacy vs. security


Identity
“Not forbidden is permitted” vs. anonym users
Tussle space (3)

Openness



The openness to innovation that permits a new application
to be deployed
Economical motivations
 Proprietary interfaces give market power
Vertical integration by ISPs



Bundling infrastructure and services
Somewhat restricted but better QoS
Separate
 Tussle of vertical integration
 Tussle of sustaining innovation
Old principles

End to end arguments



Still valid, but need a more complex articulation
Network could provide more information (ECN, QoS)
 Motivate ISPs to modify routers
 We need the tussle of competition!
Separation of policy and mechanism



Mechanism defines the range of “policies”
No pure separation of policy from mechanism
BUT: do isolate tussle free regions of the system
 Fixed-points
Conclusion and effect

Do not deny the reality of the tussle, but recognize
our power to shape it.
A different way of thinking for system designers

2006: NSF FIND initiative starts




Clean-slate redesign of the Internet
 Economics
 Trust
This paper is a very important precursor
Great effect