Design Principles of Internet

Richard T. B. Ma

School of Computing

National University of Singapore

CS 5229: Advanced Compute Networks

References

David D. Clark, “The Design Philosophy of the DARPA Internet Protocols”, ACM Computer Communication Review Vol. 18, No. 4, August 1988, pp. 106-114.

David D. Clark, John Wroclawski, Karen R. Sollins, Robert Braden, “Tussle in Cyberspace: Defining Tomorrow’s Internet”, IEEE/ACM Transactions on Networking, Vol. 13, No. 3, June 2005.

The Born of the Internet

The TCP/IP protocol suite was developed by the US Defense Advanced Research Projects Agency (DARPA) in the 70’s.

Fundamental Goal: interconnect disjoint networks and share resources effectively ARPANET and ARPA packet radio network

Enable ARPA packet radio network users access to more powerful ARPANET service machines

Design Choices and Reasoning

A. Build a tightly integrated, unified network

B. Interconnect existing networks

A. Packet switching

B. Circuit switching

Design Choices and Reasoning

A. Build a tightly integrated, unified network

B. Interconnect existing networks

Incorporate existing networks is necessary to be practical, and networks represent separately administrated entities.

A. Packet switching

B. Circuit switching

Existing networks used packet switching, natural choice for remote login application.

The Fundamental Structure

Assumption: Store and forward packet switching techniques

are well understood.

Packet switching networks connected by “gateways”, i.e., the routers

Each router implements a store and forward mechanism

Second Level Goals

Accommodate a variety of networks

Allow host attachment with minimum effort

Communication must continue despite loss of networks/gateways

Cost effective

Permit distributed management of its resources

Resources must be accountable

Support multiple types of communication services

Order of Importance/Priorities

Robustness: communication must continue despite loss of networks/routers

Versatility: accommodate a variety of services and networks

Distributiveness: permit distributed management of its resources

Cost effectiveness

User friendliness: allow host attachment with minimum effort

Accountability of resources

Robustness: Interpretation

Survivability in the face of failure

Communication should continue after temporary disruption without the need to reset high-level connection states.

From above the transport, the only observable failure is total partition, which is achieved by masking transient failures.

High-level on-going state information must be protected.

Design Choices and Reasoning

Store connection/flow states in:

A. Packet switching nodes (replication)

B. End nodes (fate-sharing)

Easier to implement than replication

Replication only protects against finite number of node failures.

Stateless or datagram network

More trust is placed on the host machines than the network to ensure reliability

Versatility: Types of Services

Remote login Need low delay and reliability

Throughput is not critical

File transfer Need reliability and high throughput

Delay is not critical

Teleconferencing Need low delay

Reliability is not critical

Design Choices and Reasoning

How to provide multiple services?

A. A suite of protocols for various services

B. A single protocol to support all services

Difficult, e.g. reliability versus delay

Flexibility, designed protocols cannot turn off features, e.g. X.25 can’t be unreliable

Layered protocol stack TCP (reliable service)/UDP (low delay service)

IP (datagram based, best effort)

Versatility: Types of Networks

Able to incorporate and utilize Long-haul networks, e. g. ARPANET, X.25 nets

Local area networks, e. g. Ethernet

Broadcast satellite and packet radio networks

Various types of links and ad hoc facilities

Minimally assumed

Can transport packet

Best effort delivery

Addressing (IP)

Minimum packet size

Not Assumed Sequenced delivery

Packet prioritization

Broadcast/multicast

Network states

Order of Importance/Priorities

Robustness: communication must continue despite loss of networks/routers

Versatility: accommodate a variety of services and networks

Distributiveness: permit distributed management of its resources

Cost effectiveness

User friendliness: allow host attachment with minimum effort

Accountability of resources

Other Goals

Distributiveness Routing is controlled by autonomous systems

Lack of distributed tools for management

Cost effective Not, compared to more tailored architectures

Header is large (40 bytes for TCP)

End-to-end retransmission can be expensive

Allow host attachment with small effort End hosts need to implement the protocols

Resources accountability Few tools/mechanisms (Why?)

References

David D. Clark, John Wroclawski, Karen R. Sollins, Robert Braden, “Tussle in Cyberspace: Defining Tomorrow’s Internet”, IEEE/ACM Transactions on Networking, Vol. 13, No. 3, June 2005.

What Is Tussle?

Today’s Internet Landscape

Users

Commercial ISPs

Private sector network providers

Governments

Intellectual property rights holders

Providers of content and higher level services

Tussle: Conflicting Interests

Music lovers want to exchange records; rights holders want to stop them.

People want to talk in private; government wants to tap their conversations.

Corporations put users behind firewalls; users route and tunnel around them.

ISPs give users a single IP address; users attach a network of computers using NAT.

Why? Engineering Vs. Society

Engineers: solve the problems by designing mechanisms with predictable consequences.

Society: dynamic management of evolving and conflicting interests.

Internet has evolved from an engineering entity to a society.

Cyber Tussles: How Different?

Traditional tussles occur at Design time

Re-design time

Configuration time

Internet tussles occur at Run time

Not predictable

Perspectives of Tussles

Business innovation perspective The Innovator’s Dilemma

Law perspective Non-neutral values into the design

Economics perspective Pricing, strategy, behavior, incentive …

System design perspective

Design Choices and Reasoning

How to shape the nature of tussles?

A. Embed values into design

B. Design for choice at run time

C. Sit outside the tussles

Rigid designs could be biased & irreversible

Flexible, option for evolution and innovation

As designers, we do have values and unique power to create the technology

Design Principles for Tussles

Design for choice Protocols should be designed such that all

parties have the ability to express preferences without breaking the application

Modularize along tussle boundaries One tussle does not spill over and distort

unrelated issues

Less efficient solution may provide better isolation, e.g. separate trademark from DNS

Example: ToS bit design for IP QoS

Tussle Space: Economics

Providers tussle as they compete

Consumers tussle with providers to get desired services with low prices

Design for choice and tussle separation come into play

IP Address Lock-In

ISPs want to lock in their (corporate) customers using static IP addresses

Users want the ability to change providers

Design for choice: incorporate mechanisms that make it easy for a host to change address: DHCP, DNS dynamic update

Modularize tussle: addresses should reflect connectivity, not identity.

Value Pricing

Service differentiation increases revenue, e.g. “Saturday night stay policy”

ISPs want to charge business rate for users who run a server or a small network

Users want to avoid paying high rate

Design for choice: tunneling and NAT

No value-neutral design here: value shifted toward consumers

Residential Broadband Access

Concern about reduction in competition

Pessimistic view: 2 choices in future Your telephone or cable company

Regulation for “open access” that forces wire owners to allow multiple ISPs to use

Design for choice: Municipal deployment of fiber optics as a platform for competitors

Isolate tussle: Research becomes how to support competition in high-level services

Competitive Wide Area Access

Choice for “long distance provider” was not designed for the Internet

Policy-based routing is needed, should users or providers decide policy? User control needs the change for IP!

Pragmatic choice for provider control: BGP

Incentive for providers to deploy

Less service diversity, e.g. no QoS

Need for payment in order to support source routing, incentive matters.

Tussle Space: Trust, Openness

Users do not trust each other.

the parties they want to talk to

the software they have to run

Suggestion: “design for choice”

Openness ≈ Competition, Innovation Open system versus proprietary systems

Suggestion: isolate the tussle of vertical integration from the wish to sustain innovation

Lessons: QoS Deployment

Fail to provide QoS as an open end-to-end service, so as multicast services.

Implementation incur costs; ISPs do not have incentives

Competitive pressure is not sufficient

Failure to make value transfer and couple choice of QoS with choice of provider

ToS bit to express user choice; routing?

More Tussles

Network Neutrality Debate QoS is not provided; however, should ISPs be

allowed to differentiated services?

Drop/price packets based on contents?

ISPs settlement ISPs are connected to one another to provide

universal connectivity; however, compete …

Who should pay who? How much?

If disagreed, how to resolve?

The End-to-end Argument

In a layered architecture, what services should be implemented at what layer?

A service should be carried out in a layer if needed by all clients of that layer

can be completely implemented in that layer

Design principle: “stupid” network. Minimize lower layer functions, support variety of services, and let applications adapt.

Reliability at transport layer; best-effort datagram delivery at network layer.

Readings: End-to-end Argument

J. H. Saltzer, D. P. Reed and D. D. Clark, “End-to-end arguments in system design”, ACM Transactions on Computer Systems, Vol. 2, No. 4, pp. 277 –288, 1984.

Marjory S. Blumenthal, David D. Clark, “Rethinking the design of the Internet: the end-to-end arguments vs. the brave new world”, ACM Transactions on Internet Technology, Vol. 1 No. 1, August 2001.

Readings: Network Neutrality

“Network neutrality”, Wikipedia

Tim Wu, “Network Neutrality, Broadband Discrimination“, J. of Telecommunications and High Technology Law, Vol. 2, 2003

Edward Wyatt, “Google and Verizon Near Deal on Web Pay Tiers”, The New York Times, August 4, 2010.

Chapter 1 Introduction

Computer Networking: A Top Down Approach , 5th edition. Jim Kurose, Keith Ross Addison-Wesley, April 2009.

A note on the use of these ppt slides: We’re making these slides freely available to all (faculty, students, readers).

They’re in PowerPoint form so you can add, modify, and delete slides

(including this one) and slide content to suit your needs. They obviously

represent a lot of work on our part. In return for use, we only ask the

following:

If you use these slides (e.g., in a class) in substantially unaltered form, that

you mention their source (after all, we’d like people to use our book!)

If you post any slides in substantially unaltered form on a www site, that

you note that they are adapted from (or perhaps identical to) our slides, and

note our copyright of this material.

Thanks and enjoy! JFK/KWR

All material copyright 1996-2010

J.F Kurose and K.W. Ross, All Rights Reserved

Introduction 1-36

Internet History

1961: Kleinrock - queueing theory shows effectiveness of packet-switching

1964: Baran - packet-switching in military nets

1967: ARPAnet conceived by Advanced Research Projects Agency

1969: first ARPAnet node operational

1972:

ARPAnet public demonstration

NCP (Network Control Protocol) first host-host protocol

first e-mail program

ARPAnet has 15 nodes

1961-1972: Early packet-switching principles

Introduction 1-37

Internet History

1970: ALOHAnet satellite network in Hawaii

1974: Cerf and Kahn - architecture for interconnecting networks

1976: Ethernet at Xerox PARC

late70’s: proprietary architectures: DECnet, SNA, XNA

late 70’s: switching fixed length packets (ATM precursor)

1979: ARPAnet has 200 nodes

Cerf and Kahn’s internetworking principles: minimalism, autonomy -

no internal changes required to interconnect networks

best effort service model

stateless routers decentralized control

define today’s Internet architecture

1972-1980: Internetworking, new and proprietary nets

Introduction 1-38

Internet History

1983: deployment of TCP/IP

1982: smtp e-mail protocol defined

1983: DNS defined for name-to-IP-address translation

1985: ftp protocol defined

1988: TCP congestion control

new national networks: Csnet, BITnet, NSFnet, Minitel

100,000 hosts connected to confederation of networks

1980-1990: new protocols, a proliferation of networks

Introduction 1-39

Internet History

early 1990’s: ARPAnet decommissioned

1991: NSF lifts restrictions on commercial use of NSFnet (decommissioned, 1995)

early 1990s: Web

hypertext [Bush 1945, Nelson 1960’s]

HTML, HTTP: Berners-Lee

1994: Mosaic, later Netscape

late 1990’s: commercialization of the Web

late 1990’s – 2000’s: more killer apps: instant

messaging, P2P file sharing

network security to forefront

est. 50 million host, 100 million+ users

backbone links running at Gbps

1990, 2000’s: commercialization, the Web, new apps

Introduction 1-40

Internet History

2010:

~750 million hosts

voice, video over IP

P2P applications: BitTorrent (file sharing) Skype (VoIP), PPLive (video)

more applications: YouTube, gaming, Twitter

wireless, mobility

Introduction 1-41