Scribd
Upload
28 views

Internet Architecture: CPS 214 (Nick Feamster) January 14, 2008

The document summarizes the design philosophy and goals of the original Internet architecture. The fundamental goals were to enable interconnection of existing networks through packet switching, promote resilience through fate sharing, and support heterogeneous services and networks. While this architecture enabled innovation and growth, it also resulted in tradeoffs like difficulty changing the "narrow waist" of IP, lack of network management visibility, and challenges with accountability. The document discusses how the Internet has evolved away from some of its original design priorities.

Uploaded by

sushmsn
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
28 views

Internet Architecture: CPS 214 (Nick Feamster) January 14, 2008

The document summarizes the design philosophy and goals of the original Internet architecture. The fundamental goals were to enable interconnection of existing networks through packet switching, promote resilience through fate sharing, and support heterogeneous services and networks. While this architecture enabled innovation and growth, it also resulted in tradeoffs like difficulty changing the "narrow waist" of IP, lack of network management visibility, and challenges with accountability. The document discusses how the Internet has evolved away from some of its original design priorities.

Uploaded by

sushmsn
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31

Internet Architecture

CPS 214
(Nick Feamster)
January 14, 2008
Today’s Reading
• Design Philosophy of the DARPA Internet
Protocols. Dave Clark, 1988.

• Conceptual Lessons
– Design principles/priorities were designed for a certain
type of network. As the Internet evolves, we feel the
sting of some of these choices.
Examples: Commercialization
– Engineering/Realization is key to testing an idea.
• Technical Lessons
– Packet switching
– Fate Sharing/Soft state
Fundamental Goal
• “technique for multiplexed utilization of existing
interconnected networks”

• Multiplexing (sharing)
– Shared use of a single communications channel
• Existing networks (interconnection)
Fundamental Goal: Sharing

Packet Switching
• No connection setup
• Forwarding based on destination address in packet
• Efficient sharing of resources

Tradeoff: Resource management potentially


more difficult.
Type of Packet Switching: Datagrams
• Information for forwarding traffic is contained in
destination address of packet
• No state established ahead of time (helps fate sharing)
• Basic building block
• Minimal assumption about network service
Alternatives
• Circuit Switching: Signaling protocol sets up
entire path out-of-band. (cf. the phone network)
• Virtual Circuits: Hybrid approach. Packets
carry “tags” to indicate path, forwarding over IP
• Source routing: Complete route is contained in
each data packet
An Age-Old Debate
Circuit Switching
• Resource control, accounting, ability to “pin”
paths, etc.
Packet Switching
• Sharing of resources, soft state (good resilience
properties), etc.
It is held that packet switching was one of the Internet’s
greatest design choices.
Of course, there are constant attempts to shoehorn the best
aspects of circuits into packet switching.
Examples: Capabilities, MPLS, ATM, IntServ QoS, etc.
Stopping Unwanted Traffic is Hard
February 2000 March 2006
Research: Stopping Unwanted Traffic
• Datagram networks: easy for anyone to send
traffic to anyone else…even if they don’t want it!

cnn.com

Possible Defenses
• Monitoring + Filtering: Detect DoS attack and
install filters to drop traffic.
• Capabilities: Only accept traffic that carries a
“capability”
The Design Goals of Internet, v1
• Interconnection/Multiplexing (packet switching)
• Resilience/Survivability (fate sharing)
• Heterogeneity
Decreasing
– Different types of services
Priority
– Different types of networks
• Distributed management
• Cost effectiveness “This set of goals might seem to be nothing
• Ease of attachment more than a checklist of all the desirable
network features. It is important to understand
• Accountability that these goals are in order of importance, and
an entirely different network architecture
would result if the order were changed.”

These goals were prioritized for a military network.


Should priorities change as the network evolves?
Fundamental Goal: Interconnection
• Need to interconnect many existing networks
• Hide underlying technology from applications
• Decisions:
– Network provides minimal functionality
– “Narrow waist”
email WWW phone...

SMTP HTTP RTP... Applications


TCP UDP…

IP

ethernet PPP…

CSMA async sonet... Technology


copper fiber radio...

Tradeoff: No assumptions, no guarantees.


The “Curse of the Narrow Waist”
• IP over anything, anything over IP
– Has allowed for much innovation both above and
below the IP layer of the stack
– An IP stack gets a device on the Internet

• Drawback: very difficult to make changes to IP


– But…people are trying
– NSF GENI project: http://www.geni.net/
Interconnection: “Gateways”
• Interconnect heterogeneous networks
• No state about ongoing connections
– Stateless packet switches
• Generally, router == gateway
• But, we can think of your home router/NAT as also
performing the function of a gateway

192.168.1.51 68.211.6.120:50878
Home
Internet
Network 192.168.1.52 68.211.6.120:50879
Network Address Translation
• For outbound traffic, the gateway:
– Creates a table entry for computer's local IP address
and port number
– Replaces the sending computer's non-routable IP
address with the gateway IP address.
– replaces the sending computer's source port

• For inbound traffic, the gateway:


– checks the destination port on the packet
– rewrites the destination address and destination port
those in the table and forwards traffic to local machine
NAT Traversal
• Problem: Machines behind NAT not globally
addressable or routable. Can’t initiate inbound
connections.
• One solution: Simple Traversal of UDP Through NATs
– STUN client contacts STUN server
– STUN server tells client which IP/Port the NAT mapped it to
– STUN client uses that IP/Port for call establishment/incoming
messages

Home Home
Network 1 Relay node Network 2

More next time.


Goal #2: Survivability
• Network should continue to work, even if some
devices fail, are compromised, etc.
• Failures on the Abilene (Internet 2) backbone
network over the course of 6 months

Thanks to Yiyi Huang

How well does the current Internet


support survivability?
Goal #2: Survivability
Two Options
• Replication
– Keep state at multiple places in the network, recover when nodes crash
• Fate-sharing
– Acceptable to lose state information for some entity if the entity itself is lost

Reasons for Fate Sharing


• Can support arbitrarily complex failure scenarios
• Engineering is easier

Some reversals of this trend:


NAT, Routing Control Platform
Goal #3: Heterogeneous Services
• TCP/IP designed as a monolithic transport
– TCP for flow control, reliable delivery
– IP for forwarding

• Became clear that not every type of application


would need reliable, in-order delivery
– Example: Voice and video over networks
– Example: DNS
– Why don’t these applications require reliable, in-order
delivery?
– Narrow waist: allowed proliferation of transport protocols
Topic: Voice and Video over Networks
• Deadlines: Timeliness more important than
100% reliability.
• Propagation of errors: Some losses more
devastating than others
Loss in “Anchor” Frame (I-Frame) Propagates to “Dependent” Frames
(P and B-Frames)
Goal #3b: Heterogeneous Networks

• Build minimal functionality into the network


– No need to re-engineer for each type of network
• “Best effort” service model.
– Lost packets
– Out-of-order packets
– No quality guarantees
– No information about failures, performance, etc.

Tradeoff: Network management more difficult


Research: Network Anomaly Detection

• Operators want to detect when a traffic flow from ingress


to egress generates a “spike”.
• Problem: Today’s protocols don’t readily expose this
information.
• Management/debuggability not initially a high priority!
Goal #4: Distributed Management
Many examples:
• Addressing (ARIN, RIPE, APNIC, etc.)
– Though this was recently threatened.
• Naming (DNS)
• Routing (BGP)

No single entity in charge.


Allows for organic growth, scalable management.

Tradeoff: No one party has visibility/control.


No Owner, No Responsible Party

“Some of the most significant problems with the Internet


today relate to lack of sufficient tools for distributed
management, especially in the area of routing.”

• Hard to figure out who/what’s causing a problem


• Worse yet, local actions have global effects…
Local Actions, Global Consequences
“…a glitch at a small ISP… triggered a major outage in
Internet access across the country. The problem started
when MAI Network Services...passed bad router
information from one of its customers onto Sprint.”
-- news.com, April 25, 1997

UUNet Sprint

Florida Internet
Barn
Goal #5: Cost Effectiveness
• Packet headers introduce high overhead
• End-to-end retransmission of lost packets
– Potentially wasteful of bandwidth by placing burden
on the edges of the network

Arguably a good tradeoff. Current trends are to exploit


redundancy even more.
Goal #6: Ease of Attachment

• IP is “plug and play” Anything with a working IP stack


can connect to the Internet (hourglass model)
• A huge success!
– Lesson: Lower the barrier to innovation/entry and people will get
creative (e.g., Cerf and Kahn probably did not think about IP
stacks on phones, sensors, etc.)
• But….

Tradeoff: Burden on end systems/programmers.


Goal #7: Accountability
• Note: Accountability mentioned in early papers
on TCP/IP, but not prioritized
• Datagram networks make accounting tricky.
– The phone network has had an easier time figuring
out billing
– Payments/billing on the Internet is much less precise

Tradeoff: Broken payment models and incentives.


What’s Missing?
• Security
• Availability
• Accountability (the other kind)
• Support for disconnected/intermittent operation
• Mobility
• Scaling
• …
Today’s Reading
• Design Philosophy of the DARPA Internet
Protocols. Dave Clark, 1988.
• Conceptual Lessons
– Design principles/priorities were designed for a
certain type of network. As the Internet evolves, we
feel the sting of some of these choices.
Examples: Commercialization,
– Engineering/Realization is key to testing an idea.
• Technical Lessons
– Packet switching
– Fate Sharing/Soft state
Design Goal Shakeup
• Cost of bandwidth is dropping. IP networks are
becoming a commodity.

• Management == Human intervention


– Costly!!
– Human error a leading cause of downtime

• More bandwidth: are 40-byte headers still “big”?


Today’s Reading
• Design Philosophy of the DARPA Internet
Protocols. Dave Clark, 1988.
• Conceptual Lessons
– Design principles/priorities were designed for a
certain type of network. As the Internet evolves, we
feel the sting of some of these choices.
Examples: Commercialization,
– Engineering/Realization is key to testing an idea.
• Technical Lessons
– Packet switching
– Fate Sharing/Soft state
Clark’s Paper and This Course
• Flexible architectures (Good Thing) leave a lot of
"wiggle room".
• To determine whether something's going to
work, it needs to be implemented/engineered.

You might also like