1-01_Tussle in Cyberspace Defining Tomorrow's Internet
Tussle in Cyberspace:Defining Tomorrow’s Internet
David D.Clark
MIT Lab for Computer Science ddc@lcs.mit.edu
John Wroclawski
MIT Lab for Computer Science jtw@lcs.mit.edu
Karen R.Sollins
MIT Lab for Computer Science sollins@lcs.mit.edu
Robert Braden
USC Information Sciences Institute
braden@isi.edu
Abstract
The architecture of the Internet is based on a number of principles,including the self-describing datagram packet, the end to end arguments,diversity in technology and global addressing.As the Internet has moved from a research cu-riosity to a recognized component of mainstream society, new requirements have emerged that suggest new design principles,and perhaps suggest that we revisit some old ones.This paper explores one important reality that sur-rounds the Internet today:different stakeholders that are part of the Internet milieu have interests that may be ad-verse to each other,and these parties each vie to favor their particular interests.We call this process“the tussle”.Our position is that accommodating this tussle is crucial to the evolution of the network’s technical architecture.We dis-cuss some examples of tussle,and offer some technical design principles that take it into account.
Categories and Subject Descriptors
C.2.1[Computer Systems Organization]:Computer Communications Networks—Network Architecture and De-sign;H.1[Information Systems]:Models and Principles; K.4.1[Computing Milieux]:Computers and Society—Public Policy Issues
General Terms
Design,Economics,Legal Aspects,Security,Standardiza-tion
Keywords
Tussle,Network Architecture,Trust,Economics,Design Principles,Competition
Work sponsored in part by the Defense Advanced Research Projects Agency (DARPA)and Air Force Research Laboratory,Air Force Materiel Com-mand,USAF,under agreement number F30602-00-2-0553at MIT,and agreement number F30602-00-1-0540at ISI.The U.S.Government is au-thorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on thefirst page.To copy otherwise,to republish,to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.
SIGCOMM’02,August19-23,2002,Pittsburgh,Pennsylvania,USA. Copyright2002ACM1-58113-570-X/$5.00.1.INTRODUCTION
The Internet was created in simpler times.Its creators and early users shared a common goal—they wanted to build a network infrastructure to hook all the computers in the world together so that as yet unknown applications could be invented to run there.All the players,whether designers, users or operators,shared a consistent vision and a common sense of purpose.
Perhaps the most important consequence of the Internet’s success is that the common purpose that launched and nur-tured it no longer prevails.There are,and have been for some time,important and powerful players that make up the Internet milieu with interests directly at odds with each other.
Some examples are very current.Music lovers of a cer-tain bent want to exchange recordings with each other,but the rights holders want to stop them.People want to talk in private,and the government wants to tap their conversa-tions.Some examples are so obvious that they are almost overlooked.For the Internet to provide universal intercon-nection,ISPs must interconnect,but ISPs are sometimes fierce competitors.It is not at all clear what interests are being served,to whose advantage,to what degree,when ISPs negotiate terms of connection.It is not a single happy family of people dedicated to universal packet carriage. We suggest that this development imposes new require-ments on the Internet’s technical architecture.These new requirements,in turn,motivate new design strategies to ac-commodate the growing tussle among and between different Internet players.
The purpose of this paper is to explore what these requirements and strategies might be.
We begin by briefly discussing the Internet landscape-some fundamental differences between the mechanisms of engineering and society,and the players that populate our field.We then outline some proposed design principles in-tended to accommodate within the Internet mechanisms of society as well as those of engineering.We believe this ac-commodation is central to designing an Internet that is re-silient to the challenges of society as well as those of tech-nology.We conclude by discussing some tussle spaces,ways in which our principles might guide the technical response to these spaces,and specific technical research that may be of value in accommodating these tussles.
1.1The natures of engineering and society Engineers attempt to solve problems by designing mech-
anisms with predictable consequences.Successful engineer-ing yields bridges that predictably don’t fall down,planes that predictably don’t fall out of the sky,and calculators that give the“right”answer.The essence of engineering is the development and codification of models,techniques and tools that deliver predictable,desirable behavior.
The technical development of the Internet has followed this path.As a community,we focus on design princi-ples that deliver such virtues as robustness,scalability and manageability in the face of comple
xity,component failures, growth,and other challenges.However,as the Internet be-comes mainstream it inevitably moves from being an engi-neering curiosity to being a mirror of the societies in which it operates.The Internet may have been designed by engi-neers,but its behavior(and its evolution)is by no means predictable today.
The operation of societies follows a different model.His-torically,the essence of successful societies is the dynamic management of evolving and conflicting interests.Such so-cieties are structured around‘controlled tussle’–regulated by mechanisms such as laws,judges,societal opinion,shared values,and the like.Today,this is the way the Internet is defined—by a series of ongoing tussles.Different parties adapt its mix of mechanisms to try to achieve their conflict-ing goals,and others respond by adapting the mechanisms to push back.Thus,conservative governments and corpo-rations put their users behindfirewalls,and the users route and tunnel around them.ISPs give their users a single IP address,and users attach a network of computers using ad-dress translation.There is no“final outcome”of these in-teractions,no stable point,and no acquiescence to a static architectural model.
The challenge facing Internet research and engineering is to recognize and leverage this reality–at minimum to ac-commodate it;if possible,to use it to strengthen the techni-cal architecture.In other wo
rds,the technical architecture must accommodate the tussles of society,while continuing to achieve its traditional goals of scalability,reliability,and evolvability.This expansion of the Internet’s architectural goals is a difficult,but central technical problem.
1.2The Internet landscape
Today,there are many parties that are part of the Internet milieu.These include:
•Users,who want to run applications and interact over the Internet.
•Commercial ISPs,who sell Internet service with the goal of profit.
•Private sector network providers who run a part of the Internet to facilitate their business or other undertak-ing.
•Governments,who enforce laws,protect consumers, regulate commerce,and so on.
•Intellectual property rights holders,who want to pro-tect their materials on the Internet.
•Providers of content and higher level services,offered in search of profit or as a public service.
There is great diversity within each of these categories: there are“good users”and spammers,dominant ISPs and small players,private providers with more or less rigidity about usage,liberal and conservative governments,and so on.The resulting tussles span a broad scope:the rights of the individual vs.the state,the profit seeking of com-petitors,the resistance to those with malicious intent,those with secrets vs.those who would reveal them,and those who seek anonymity vs.those would identify them and hold them accountable.The list probably mirrors every aspect of society.For a detailed discussion of these various players and their impact on the Internet,see[1].
2.PRINCIPLES
The thesis of this paper is that the future of the Inter-net will increasingly be defined by tussles that arise among the various parties with divergent interests,and that the technical architecture of the Internet must respond to this observation.If this is so,are there principles to guide de-signers,and mechanisms that we should use in recognition of this fact?
In this paper we offer some design principles to deal with tussle.Our highest-level principle is:
•Design for variation in outcome,so that the outcome can be different in different places,and the tussle takes place within the design,not by distorting or violating it.Do not design so as to dictate the
outcome.Rigid designs will be broken;designs that permit variation willflex under pressure and survive.
Within this guiding principle,we identify two more specific principles:
•Modularize the design along tussle boundaries,so that one tussle does not spill over and distort unrelated issues.
•Design for choice,to permit the different players to express their preferences.
2.1Modularize along tussle boundaries Systems designers know to break complex systems into modular parts.Modularity is typically used to manage com-plexity,allow for independent implementation and compo-nent reuse,or to meet other technical goals.But“tussle isolation”is perhaps a new principle.
•Functions that are within a tussle space should be log-ically separated from functions outside of that space, even if there is no compelling technical reason to do so.
Doing this allows a tussle to be played out with min-imal distortion of other aspects of the system’s func-tion.
The design of the DNS provides an example.The current design is entangled in debate because DNS names are used both to name machines and to express trademark.In retro-spect,one might have predicted thatfights over trademarks would be a tussle space,and made sure that the names that expressed trademarks were used for as little else as possible. In particular,one might imagine separate strategies to deal with the issues of trademark,naming mailbox services,and
providing names for machines that are independent of loca-tion(the original and minimal purpose of the DNS).One could then try to design these latter mechanisms to try to duck the issue of trademark.
•Solutions that are less efficient from a technical per-spective may do a better job of isolating the collateral damage of tussle.
In contrast,the current trajectory of IP QoS design tries to isolate tussles.The use of explicit ToS bits to select QoS, rather than binding this decision to another property such as a well-known port number,disentangles what application is running from what service is desired.It can be anticipated that there will be tussles about what applications a user can run,and separately tussles about what service qualities can be provided.The designers felt that it was better to sepa-rate these ideas.This modularity allows tussles about QoS to be played out without distortions,such as demands that encry
ption be avoided simply to leave well-known port in-formation visible or the encapsulation of applications inside other applications simply to receive better service.
2.2Design for choice
Network protocols are designed so that different parties on the network can communicate with each other,consumers can make use of the resources of providers,and providers can interconnect with each other to provide service.It is impor-tant that protocols be designed in such a way that all the parties to an interaction have the ability to express prefer-ence about which other parties they interact with.Protocols must permit all the parties to express choice.
For example,the design of the mail system allows the user to select his SMTP server and his POP server.A user can pick among servers,perhaps to avoid an unreliable one or pick one with desirable features,such as spamfilters.Users can select what news server they use,perhaps to prevent their children from encountering some of the more color-ful news groups.This sort of choice drives innovation and product enhancement,and imposes discipline on the mar-ketplace.
The form that the choice takes for the different parties may be different.A user of mail might choose her SMTP server by configuring a mail-sending program.An ISP might try to control what SMTP serv
er a customer uses by redi-recting packets based on the port number.1
Providing this sort of choice has a drawback—it adds to the complexity of configuring and using a service.For na¨ıve users,choice may be a burden,not a blessing.To compen-sate for this complexity,we may see the emergence of third parties that rate services(the on-line analog of Consumers Reports)and parties that provide pre-configured software to relieve the user of dealing with the details of choice. 2.3Implications
These principles,and the reality of tussle,have some fur-ther implications for design:
1An over-generalization of the tussle is that service providers exercise control over routing;end-users control selection of other end-points.End-users try to over-rule constrained routing with tunnels and overlay networks.
Choice often requires open interfaces.Open inter-faces have played a critical role in the evolution of the In-ternet,by allowing for competition among algorithms,im-plementations,and vendors,and by enabling rapid techni-cal progress through replacement of modular parts rather than entire systems.But open interfaces also allow choice, not just replacement.If a protocol allows a party to select among alternative providers of service,this usually implies that the interface to that service is w
ell-defined,so that in-dependent versions of the service can be constructed. Tussles often happen across interfaces.Some tussles involve the use of different mechanisms by different parties. However,some tussles,such as the tussle among compet-itive ISPs,may involve technical interfaces between those parties.For example,BGP is used as the routing protocol among ISPs,who interconnect but are business competitors. If an interface occurs at a point of tussle,it will have differ-ent attributes from an interface that exists simply to foster interoperability,modularity,or competition among suppli-ers.
Open interfaces at tussle points may benefit from the fol-lowing sorts of properties,which are not always important in other cases.
•Visible exchange of value.
•Exposure of cost of choice.
•Visibility(or not)of choices made.
•Tools to resolve and isolate faults and failures.
It matters if the consequence of choice is visible. Choices made in public are sometimes different tha
n those made in secret.In some cases,there is no way to hide a choice.Often,the choice can be secret,even if its conse-quences are visible.The routing arrangements among ISPs are generally not public,even though everyone can see the consequences at the BGP level.A link-state routing pro-tocol requires that everyone export his link costs,while a distance vector protocol makes it harder to see what the internal choices are.
Tussles have differentflavors.In some cases,the in-terests of the players are simply adverse,and there is no win-win way to balance them.But in many cases,players’interests are not adverse,but simply different.A user wants to send data;a provider wants to be compensated for car-rying it.While this implies a natural tussle over pricing,in the end both parties realize that they must meet the other’s needs.
To support this class of tussle,recognize that there is often an exchange of value for service.Value need not be“money”but often will be.Napster is a non-monetary example that illustrates the“mutual aid”aspect of peer-to-peer network-ing.Whatever the compensation,recognize that it must flow,just as much as data mustflow.Sometimes this hap-pens outside the system,sometimes within a protocol.If this“valueflow”requires a protocol,design it.(There is an interesting case study in the rise and fall of micro-payments, the success of the traditional credit card companies for In-ternet payments,and the
emergence of PayPal and similar schemes.)
Tussles evolve over time.A traditional engineering design produces a result that is constant until the mecha-nism is redesigned.But tussle is ongoing and evolutionary.
Each sidefinds new ways to gain an advantage,and then the other side responds.This implies,first,that any think-ing about tussle must view it as a multi-round process,and second,that as mechanism is drawn into an ongoing tussle, it may be used in unexpected ways,and require redesign to survive in this new role.
There is no such thing as value-neutral design. What choices designers include or exclude,what interfaces are defined or not,what protocols are open or proprietary, can have a profound influence on the shape of the Internet, the motivations of the players,and the potential for distor-tion of the architecture.
Don’t assume that you design the answer.You are designing a playingfield,not the outcome. 3.TUSSLE SPACES
In this section we discuss some specific aspects of the In-ternet in which different players with comp
eting interests come together.In each case,our goal is to examine the na-ture of the tussle and to illustrate how our principles can be applied in specific cases.We suggest some specific research areas that would benefit from application of our principles.
3.1Economics
One of the tussles that define the current Internet is the tussle of economics.The providers of the Internet are not in the business of giving service away.For most,it is a business, run to make a profit.This means they are competitors,and look at the user,and each other,as a customer and a source of revenue.Providers tussle as they compete,and consumers tussle with providers to get the service they want at a low price.2
How can we,as engineers,shape the economic tussle?In fact,we have great power to shape this tussle,butfirst we have to understand the rules that define it.A standard business saying is that the drivers of investment are fear and greed.Greed is easy to understand—it drove hundreds of billions of dollars worth of investment in telecommunica-tions over the last decade,much of which now sits at risk of bankruptcy.But fear is more subtle.The vector of fear is competition,which results when the consumer has choice. The tussle among providers and consumers in a competitive landscape is the
most basic attribute of a marketplace.Most economists of a“western”bent would argue that competi-tion is good:it drives innovation,disciplines the market, insures efficiency,and removes the need for intervention and regulation of a market.To make competition viable,the consumer in a market must have the ability to choose.So our principle that one should design choice into mechanism is the building block of competition.
Here are some specific examples,with implications for re-search and network design:
3.1.1Provider lock-in from IP addressing
2There is now considerable interest in the economics com-munity in the nature of the Internet.Some of the seminal papers are published in[9].For an overview of the current literature on Internet economics,see the Web site main-tained by Mackie-Mason at china.si.umich.edu/ telecom/net-economics.html.
ISPs would like tofind ways to lock in their customers; customers want to preserve the ability to change among providers.This illustrates the basic consumer-producer tus-sle in a competitive world.For hosts that use static ad-dresses,renumbering is a complex task.Because renum-bering hosts can be hard,there is a very explicit tension today between the desire to have addresses reflect
topology to support efficient routing and the desire of the customer to change providers easily.Either a customer is locked into his provider by the provider-based addresses,or they obtain a separate block of addresses that are not topologically signif-icant and therefore add to the size of the forwarding tables in the core of the network.Many ISP’s refuse to route small address blocks,nominally protecting the routing tables but also locking the customer to their address range.The re-sponses by the consumer include dynamic host numbering (DHCP)and dynamic update of DNS entries when the host is renumbered.
•A desire for vigorous competition would suggest that the consumer should have the choice to move from ISP to ISP.Given that,the Internet design should incorpo-rate mechanisms that make it easy for a host to change addresses and to have and use multiple addresses.
Addresses should reflect connectivity,not identity,to modularize tussle.This would relieve problems with end-node mobility,improve choice in multi-homed ma-chines,and improve the ease of changing providers. 3.1.2Value pricing
One of the standard ways to improve revenues is tofind ways to divide customers into classes based on their willing-ness to pay,and charge them accordingly—what economists call value pricing.An exa
mple from another sector is the “Saturday night stay”criterion for airline travel.It costs the airline no more to carry a passenger if she does not stay over Saturday night,but this restriction tends to separate the business and pleasure traveler,which is useful because the business traveler seems to have a greater willingness to pay.Airlines impose Saturday night stay restrictions,and consumers respond by buying multiple tickets,and using only some of the segments of theflight.Airlines respond by declaring this behavior unacceptable.And thus the tussle evolves.
As an example of similar behavior in the Internet,some acceptable use policies for residential broadband access pro-hibit the operation of a server in the home.To run a server, the customer is required to pay a higher“business”rate. Customers who wish to sidestep this restriction can respond by shifting to another provider,if there is one,or by tunnel-ing to disguise the port numbers being used.The probable outcome of this tussle depends strongly on whether one per-ceives competition as currently healthy in the Internet,or eroding to dangerous levels.
•This discussion illustrates the observation that there may be no such thing as value-neutral design.The de-sign and deployment of tunnels(or other mechanisms to mask what services are being used by a consumer) shifts the balance of power from the producer to the consumer.Given that value pricing is not a moral wrong,should the consumers be aided in their quest to bypass the control
s of the producers?Those who
see the consumer as“the little guy”being abused by the“big providers”will design such mechanisms,and this is part of the tussle,not something that happens outside the tussle.What mechanisms get designed, and what standards get approved,are all part of the tussle.
3.1.3Residential broadband access
There is concern today that the advent of broadband res-idential access will be accompanied by a great reduction in competition.Today there are almost6000dialup Internet service providers.A pessimistic outcomefive years in the future is that the average residential customer will have two choices—his telephone company and his cable company,be-cause they control the wires.This loss of choice and compe-tition is viewed with great alarm by many,who fear that it may lead to higher prices and restrictions on what the user may do,and there are many forces aligning tofight this loss of competition.Some are regulatory,calling for laws to mandate“open access”,to force the owners of the wires to allow multiple ISPs to use them.Economists and regulators hope that multiple providers will install their own cables,to increase competition.3However,in a tussle of competition, one cannot compel a potential provider to invest and enter a market.
Using the principles of this paper,one should speculate on what sorts of investments are actually likely to be made, and to think about what choice,and what tussle modular-ity,would improve the outcome of such an investment.One investment option that is gaining momentum now is munic-ipal deployment offiber,becausefiber installed by a neutral party such as a municipality can be a platform for competi-tors to provide higher level phone,Internet or television).This requires that the equipment lighting thefiber support multiple service providers.Most of the equipment made today is not“naturally open”in this way, having been designed without consideration of this particu-lar modularity boundary(or indeed with the specific goal of confounding it).
•An important R&D project is to design and demon-strate afiber-based residential access facility that sup-ports competition in higher-level services.Technical questions include whether sharing should be in the time domain(packets)or color domain,how the fair-ness of sharing can be enforced and verified,an ap-proach to fault isolation and other operational issues, and how incremental upgrades can be done.This pro-ject is motivated both by the principle of“design for choice”,and as well by recognition of new tussle bound-aries.
Most of today’s“open access”proposals fail to balance the interests of concerned parties because they are not mod-ularized along tussle space boundaries.For example,the capital costs and deploym
ent pragmatics of broadband in-frastructure differ greatly from those of operating mail and web servers.This creates a natural boundary between the two tussle spaces of broadband facilities provision and ISP services.Proposals that implement open access at this mod-ularity boundary are more likely to benefit the Internet as a 3For an analysis of issues in residential broadband access, see[3].whole,because they allow each tussle to play out indepen-dently.
3.1.4Competitive wide area access
Today,the Internet system does not let the individual cus-tomer select his“long distance provider”the way the tele-phone system does.This is an example of designers failing to appreciate a competitive tussle space.
At the time that equal access was being introduced into the telephone system,there was a call for Internet routing to support the same capability.The Internet designers deemed this not necessary.They reasoned that there would be suf-ficient competition in the market because there were going to be many ISP’s directly competing to serve the customer. Letting the local provider enter into a wholesale arrange-ment to obtain wide area service seemed adequate,because if one local provider made an unsatisfactory choice in wide area provider,the customer could just switch to a new local provider.
But this decision may be having undesirable consequences today.It is possible that customers today would be much more likely to see more service diversity, e.g.quality of service support for applications,if there were more compe-tition.
•The Internet should support a mechanism for choice of source routing that would permit a customer to con-trol the path of his packets at the level of providers.
A design for such a system must include where these
user-selected routes come from or how they are con-structed,how failures are managed,and how the user knows that the traffic actually took the desired route.
The capability must also be approachable by a broad class of users of varying sophistication.This is a very complex design challenge,4but could have a great in-fluence.
This example illustrates another important point about competition.One should be prepared to pay for what one uses,or there is little incentive for a provider to offer it.To-day,service providers do not like loose source,because ISPs don’t receive any benefit when they carry traffic directed by a source route.ISPs enter into business arrangement that determine which traffic they agree to carry across w
hich in-terfaces,and a source route has the effect of overriding these arrangements.Why should they be enthusiastic about this? Since source routes don’t work effectively today,researchers propose even more indirect ways of getting around provider-selected routing,such as exploiting hosts as intermediate forwarding agents.(This kind of overlay network is a tool in the tussle,certainly.)Another,perhaps simpler,approach is to compensate the provider for carrying the packets.But this idea tends to upset designers as well as customers,be-cause they fear they will end up in an onerous“pay by the byte”situation,which does not seem to have much market appeal.
•The design for provider-level source routing must in-corporate a recognition of the need for payment.There 4In particular,today’s loose source routes,even if widely implemented,would provide only a small portion of what is needed.
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议