Transcript The Internet: Co-Evolution of Technology and Society

Internet History, Architecture,
and Routing
ECON 425/563 & CPSC 455/555
9/25/2008
ECON 425/563
& CPSC 455/555
9/25/2008
1
Internet History
• Late 1960s and early 1970s: ARPANET
– US Department of Defense
– Connects small ARPA-sponsored data networks
– Ground breaking testbed for network ideas and
designs
• Early 1980s: Other wide-area data networks are
established (e.g., BITNET and Usenet).
• Late 1980s and early 1990s:
– “ARPANET” fades out.
– US Gov’t sponsors NSFNET, which connects large
regional networks.
– Commercial data networks become popular
(e.g., Prodigy, Compuserve, and AOL).
• Mid-1990s: Unified “Internet”
2
Internet Protocols Design
Philosophy
• Ordered set of goals:
1. multiplexed utilization of existing networks
2. survivability in the face of failure
3. support multiple types of communications service
4. accommodate a variety of network types
5. permit distributed management of resources
6. cost effective
7. low effort to attach a host
8. account for resources
• Not all goals have been met
3
Packets!
• Basic decision: use packets not circuits (Kleinrock)
• Packet (a.k.a. datagram)
Dest Addr
–
–
–
–
–
Src Addr
payload
self contained
handled independently of preceding or following packets
contains destination and source internetwork address
may contain processing hints (e.g., QoS tag)
no delivery guarantees
– net may drop, duplicate, or deliver out of order
– reliability (where needed) done at higher levels
4
Telephone Network
• Connection-based
• Admission control
• Intelligence is
“in the network”
• Traffic carried by
relatively few,
“well-known”
communications
companies
Internet
• Packet-based
• Best effort
• Intelligence is
“at the endpoints”
• Traffic carried by
many routers,
operated by a
changing set of
“unknown” parties
5
(a)
Directly Connected
Machines
(b)
• (a) Point-to-point: e.g., ATM
• (b) Multiple-access: e.g., Ethernet
• Can’t build a network by requiring all nodes
to be directly connected to each other;
need scalability with respect to the number
of wires or the number of nodes that can
attach to a shared medium
6
Switched Network
routers
hosts
• Circuit switching vs. packet routing
• Hosts vs. “the network,” which is made
of routers
• Nice property: scalable aggregate
throughput
7
Interconnection of Networks
hosts
gateway
Recursively build larger networks
8
Some Hard Questions
hosts
gateway
• How do hosts share links?
• How do you name and address hosts?
• Routing: Given a destination address,
how do you get to it?
9
IP Addresses and
Host Names
• Each machine is addressed by an integer, its
IP address, written down in a “dot notation”
for “ease” of reading, such as 128.36.229.231
• IP addresses are the universal IDs that are
used to name everything.
• For convenience, each host also has a
human-friendly host name. For example,
128.36.229.231 was concave.cs.yale.edu.
• Question: How do you translate names into
IP addresses?
10
Domain Hierarchy
edu
Yale
MIT
com
gov
mil
org
net
uk
fr
Cisco . . . Yahoo
Math CS Physics
concave cyndra netra
• Initially, name-to-address mapping
was a flat file mailed out to all the
machines on the Internet.
• Now, we have a hierarchical
name space, just like a UNIX
file-system tree.
• Top-level names (historical influence):
heavily US-centric, governmentcentric, and military-centric view
of the world
11
DNS Zones and
Name Servers
edu
Yale
MIT
com
gov
mil
org
net
uk
fr
Cisco . . . Yahoo
Math CS Physics
concave cyndra netra
• Divide up the name
hierarchy into zones.
• Each zone corresponds
to one or more name
servers under the same
administrative control.
12
Hierarchy of Name Servers
Root name server
Yale name server
CS name server
...
Cisco name server
EE name server
• Clients send queries to name servers.
• Name servers reply with answers or forward
requests to other name servers.
• Most name servers perform “lookup caching.”
13
Application-Level Abstraction
host
application
host
host
application
host
host
• What you have: hop-to-hop links, multiple routes,
packets, can be potentially lost, can be potentially
delivered out-of-order
• What you may want: application-to-application
(end-to-end) channel, communication stream,
reliable, in-order delivery
14
Basic Architectural
Principle: Layering
HTTP
(Web)
Domain Name
Service
Telnet
Transmission Control
Protocol
Simple Network
Management
User Datagram
Protocol
Internet Protocol
SONET
Ethernet
ATM
15
Interdomain Routing
Establish routes between autonomous systems (ASes).
Verizon
AT&T
Comcast
Qwest
Currently done with the Border Gateway Protocol (BGP).
16
Why is Interdomain Routing Hard?
• Route choices are based on local policies.
• Autonomy: Policies are uncoordinated.
• Expressiveness: Policies are complex.
Load-balance my
outgoing traffic.
Verizon
AT&T
Always choose
shortest paths.
Comcast
Qwest
My link to UUNET is for
backup purposes only.
Avoid routes
through AT&T if
at all possible.
17
BGP Route Processing (1)
• The computation of a single node repeats the following:
Receive routes
from neighbors
Update
Routing
Table
Choose
“Best”
Route
Send updates
to neighbors
• Paths go through neighbors’ choices, which
enforces consistency.
• Decisions are made locally, which preserves autonomy.
• Uncoordinated policies can induce protocol oscillations.
(Much recent work addresses BGP convergence.)
• Recently, private information, optimization, and
incentive-compatibility have also been studied.
18
BGP Route Processing (2)
IP Forwarding Table
Install forwarding
entries for best
routes
Apply Import
Policies
Receive
BGP
updates
Apply Policy =
filter routes
& tweak
attributes
Routing
Table
Storage
of routes
Best Route
Selection
Apply Export
Policies
Based on
attribute
values
Apply Policy =
filter routes
& tweak
attributes
Transmit
BGP
updates
Open-ended programming:
constrained only by vendor configuration language
19
Example: Convergence
Prefer
direct route
to d
2
1
Prefer
routes
through 2
d
20
Example: Oscillation
Prefer
routes
through 1
2
1
Prefer
routes
through 2
BGP might oscillate
forever between
1d, 2d
and
12d, 21d
d
21
Example: Convergence
Prefer
routes
through 1
2
1
Prefer
routes
through 2
d
22
Dispute Wheels
Nodes ui, hub routes Ri, and spoke routes Qi.
Each ui prefers RiQi+1 to Qi.
“No dispute wheel”
—>
robust convergence
23
Gao-Rexford Framework (1)
Neighboring pairs of ASes have one of:
– a customer-provider relationship
(One node is purchasing connectivity from
the other node.)
– a peering relationship
(Nodes have offered to carry each other’s
transit traffic, often to shortcut a longer
route.)
peer
peer
providers
customers
24
Gao-Rexford Framework (2)
• Global constraint: no customer-provider cycles
• Local preference and scoping constraints, which are
consistent with Internet economics:
Preference Constraints
k1
i
k2
R
. . . 1. . .
Scoping Constraints
d
R
. . .2. . .
provider
peer
i
customer
....
j
d
m
k
• If k1 and k2 are both customers, peers,
or providers of i, then either ik1R1 or
ik2R2 can be more valued at i.
• Export customer routes to all neighbors
• If one is a customer, prefer the route
through it. If not, prefer the peer route.
• Export peer and provider routes to
all customers only.
and export all routes to customers.
• Gao-Rexford conditions => BGP always converges [GR01]
25
Ongoing Research Challenge
Fully characterize the conditions under which BGP
converges (robustly).
• “No dispute wheel” is sufficient but not
necessary. Is it enforceable?
• On those instances on which BGP is guaranteed
to converge, how many rounds does it take to
converge?
26