Download ppt

CSE 588: Network Systems
Tom Anderson
Neil Spring
Goal

Startup CTO: someone proposes a new
networking technology, is it
a
risk you can afford to take
 a risk you can’t afford to take
 a risk you can’t afford not to take

Requires
 understanding
networking fundamentals
 critical evaluation of technology
Lecture Topics








Internet architecture
Transport (TCP)
Routing (IP)
Congestion control
Multicast (Mbone)
Real time (DiffServ)
Naming (DNS)
Security (Kerberos)








End to end principle
Reliable delivery
Robust interoperability
Resource allocation
Efficient delivery
Multimedia
Distributed state mgt
How to write a virus
Outline
Admin stuff
 How the Internet works
 Internet history: Clark paper
 Internet lessons: Saltzer paper
 Future directions and research problems
 Start on transport

Typical Class
0-60: basics (Peterson book++)
 60-150: discussion of papers
 150-180: next week preview
 Office hours: ?

Assignments + Slip Days

3 network programming assignments (30%)
 transport,
routing/congestion, multicast, in Java
5 problem sets (25%)
 paper reviews (due Wed noon -- 5%)

 evaluation,
not a summary!
Class discussion (15%)
 Paper evaluating some technology (25%)
 No exams!

Optional Discussion Section
Led by Neil Spring
 Help with:

 Design
for network programming
assignments
 Problem sets
 Understanding papers before class
 Defining final project

Time: ?
Some Definitions
Host -- computer, PDA, toaster, ...
 Link -- transmit bits

 wire
or wireless
 broadcast or switched (or both!)

Switch -- move bits between links
 packet
switching: stateless store&forward
 circuit switching: stateful, cut through
Internet -- network of networks
 network
delivers packets (& locates nodes)
 router (gateway) moves packets between
networks
 IP interoperability on top of any potential
network or link layer
– modem, Ethernet, token ring, cell phone, ADSL,
cable modem, smoke signals, …
 Minimum
possible requirements on
underlying networks
Protocols

Protocol: agreement between two
parties as to how information is to be
transmitted
 more
valuable with more users
– economic incentive to develop standards =>
lots and lots and lots of protocols
 Standardize
interfaces?
protocols vs. standardize
Layering

Build complex services on top of simpler
ones
telecollaboration
email
HTTP
NFS
rlogin
RPC
RSVP
TCP
UDP
IP
Ethernet
ATM
PPP
packet radio arpanet
modem
SONET
air
OSI Model: 7 Protocol Layers
Physical -- how to transmit bits
 Data link -- how to transmit frames
 Network -- how to route packets
 Transport -- how to send packets reliably
 Session -- how to tie groups together
 Presentation -- byte ordering, security
 Application -- everything else!

What happens when you click on
a Web link?
Your computer
www.netscape.com
?
Internet
Different kinds of addresses

Domain name (e.g. www.netscape.com)
 Global,

IP Address (e.g. 207.200.73.8)
 Global,

human readable
works across all networks
Ethernet (e.g. 08-00-2b-18-bc-65)
 Local,
works on a particular network
Finding the right IP address:
Domain Naming System (DNS)
Local
DNS server
(128.95.1.4)
Your computer
(128.95.1.24)
What’s the IP address for www.netscape.com?
Oh, you can find it at 207.200.73.8
Finding the right Ether address:
Address Resolution (ARP)
(128.95.1.4)
(128.95.1.24)
Broadcast: Anyone know the
Ethernet address for 128.95.1.4?
Ethernet
Broadcast: Yeah, I’m at
08-00-2b-18-bc-65
Ethernet
How does a packet get through
the Internet?
Routers send packet
to next closest point
H
H
H
R
R
R
H
R
R
R
R
H
R
H
H: Hosts
R: Routers
How do the routers know where
to send data?
Forwarding tables at each router
 Original Internet: manual update
 Automatic update based on “cost”

 exchange
tables with neighbors
 use neighbor with smallest hop count
 what if node says zero cost to everywhere?
Have address, now send data?

Murphy’s Law applies to networks
 Data
can be corrupted
 Data can get lost
 Data might not fit in a single packet
 Data can be delivered in the wrong order
 etc...
What if the data gets corrupted?
GET index.html
GET sex.html
Internet
Solution: Add a checksum
IP
TCP
TCP Packet Format
Data
0
15 16
source port
31
destination port
sequence number
acknowledgement number
header
length
reserved
UA P R S F
RC S S Y I
GK H T NN
TCP checksum
window size
urgent pointer
options (if any)
data (if any)
20
bytes
What if the data gets lost?
GET index.html
Internet
Solution: Timeout and retransmit
GET index.html
wait a bit,
retry
GET index.html
Internet
GET index.html
What if the data doesn’t fit?
On Ethernet, max IP packet is 1.5kbytes
 Typical web page is 10kbytes

Solution: Fragment data across packets
ml
x.ht
inde
GET
GET index.html
What if the data is out of order?
ml
inde
x.th
GET
GET x.thindeml
???

Solution: Add sequence numbers
ml 4
inde 2
x.th 3
GET 1
GET index.html
What if network is overloaded?
Data can arrive at router faster than it
can be forwarded!
 Short bursts: buffer at router
 What if buffer overflows?

 Packets
dropped and retransmitted
 Sender adjusts rate until load = resources

Called “Congestion control”
 Broadcast
network: bus arbitration
What if data has a deadline?
Ex: multimedia, teleconferencing
 Original Internet: out of luck!
 To provide guarantees, need

 admission
control
 resource management at routers
Ex: Telephone network has busy signals
+ explicit schedules at each switch
 How do we add this to the Internet?

What if multiple receivers?

Send a separate packet to each?
 what

if zillions of receivers?
Multicast
 routers

form distribution tree
What if data is dropped?
 Acks
would overwhelm sender
 Naks? if drop is early in the tree ->
overwhelm sender!
What if sender is malicious?
Every packet has source, destination IP
addresses
 But! Host can put anything in IP header

 packet
may have come from anywhere
 firewalls to enforce sanity checks
– ex: source must be from other side of wall
– ex: only allow reply packets
 encryption/digital
signatures for
authentication/privacy
Bottom Line
No magic!
 No revealed wisdom!

Internet History

Goal: effective multiplexed use of
existing networks

minimal support from underlying networks
– implies no support for multicast, real-time, fast
failover, congestion control, etc.
 packet
switching (fine-grained resource
sharing)
 routers connecting networks
Other Goals
Survive hardware failure
 Support multiple types of apps
 Run on wide variety of networks
 Distributed management of resources
 Cost-effective
 Low cost host attachment
 Accounting

Survivability

Internet approach
 Cheap,
failable components
 Stateless routers + self-healing
 Keep routing simple (non-adaptive)
 End to end recovery

Telephone approach
 Ultra
reliable switches
 Self-healing
Types of Service

Best effort
 latency
sensitive
 bandwidth sensitive

Real-time
 but
can Internet support real-time without
help from underlying networks?
Multicast
 What about congestion control?

Variety of Networks
Internet hugely successful because of it
can run on anything
 Is this still important? Consider IP on
ATM:

 ATM
uses 53 byte cells
 Poor fragmentation for IP packets
 Requires drop-tail routers
Other Goals
Distributed management => routing,
congestion control, multicast, real-time,
mobility
 Cost-effective => compared to what?

 Routers
very cost effective compared to
telephone switches
 But high drop rates, inefficient routes, etc.
More Goals

Attachment cost => $100M/year on
protocol stack by major OS vendors
 Misbehaving

hosts => still a problem!
Accountability
 Can
a free Internet survive?
Lessons from the Internet
experience
Saltzer paper: end to end principle
 Other lessons?

End to end principle
Functionality should be implemented at
a lower layer iff it can be correctly and
completely implemented there
 Early example

 ARPANet
provided reliable link transfers
between switches
 Packets could still get corrupted on hostswitch link, or inside switches
Example: reliable file transfer

From disk on file (web) server over
network to client
 Disk
can introduce bit errors
 Host I/O buses can introduce bit errors
 Packets can get garbled, dropped,
misordered at any node

Solution: Integrity check on file, not per
packet or per hop
Hop by hop as performance opt
Doesn’t violate end to end principle to
provide reliability at link layer, if not
required for correct operation
 Back of the envelope:

N
hops (average Internet route = 15 hops)
 Prob(corrupted packet per link) = p
 Prob(packet lost end to end)
– p = 0.0001% => Prob(loss) = 0.0015%
– p = 1% => Prob(loss) = 14%
Question

End to end principle widely followed
within Internet community, but not
elsewhere. Why?
 Checksum
on end to end network transfer
 Disk does its own error detection/correction
(inter-sector gap)
 I/O bus and memory have ECC (or nothing)

Has hardware become reliable enough?
Other Examples

Distributed transactions
 Exactly
once vs. at most once vs. at least
once

Security
 security
only as strong as weakest
assumption
Suppressing duplicate messages
 Misordered messages

Implication of End to End
Principle

Internet assumption: minimal support
from underlying network
 Ensure
Internet can run on anything
+ end to end principle
 => almost everything done at end hosts
 Telephone network has stupid endpoints

 what
happens when light switch runs TCP?
Examples

What should be done at the end hosts,
and what by the network?
 Addressing/routing?
 Reliable
delivery?
 Sequenced delivery?
 Congestion control/resource allocation?
 Real-time guarantees?
 Security?
 Multicast?
Lessons: Intuition doesn’t scale

Something breaks everytime you scale
by an order of magnitude
 Internet
has added
– automatic monitoring and repair of failed
hardware
– deadlock avoidance
– end to end reliability
– automatic name translation
– congestion avoidance
– hierarchical routing
Other Lessons

Use soft state
 robustness

via self-healing
Use hierarchy
 Ex:
routing tables based on IP prefix
 Ex: route between organizations

Propagate bad news quickly, good news
slowly
 What
is the Internet’s MTTF/MTTR?
Other Lessons

Introduce randomness
 Easy
to inadvertently synchronize
hosts/routers
Shared learning
 Let receivers decide where possible

 Multicast

groups, RSVP
Let apps decide where possible
 Application-level
framing
New Directions

Active Networks
 Computation
in the network
– Extensibility
– Performance (move computation to data)
 What
should be active?
– Active packets to control routing
– Active applications
– Active connections
– Active edge routers/gateways/firewalls
Time to Rethink?
1980's Internet
2000's Internet
Low bandwidth * delay
Low drop rates, < 1%
Few, long-lived flows
Every host a good citizen
High bandwidth * delay
High drop rates, > 5%
Many short-lived flows
TCP "accelerators" &
inelastic traffic
Symmetric routes &
Assymetric routes &
universal reachability
private peering
Hosts powerful &
Hosts = toasters &
routers overwhelmed
routers intelligent?
Limited understanding of ATM and MPP network
packet switching
design experience
End to end
principle
Future Challenges

Computers embedded in zillions of
devices (toasters, coke cans, etc.)
 does
routing/congestion control scale?
 Will they all run TCP?

Internet telephony
 data
traffic will surpass voice in 2002
 can the Internet provide high enough
reliability? (e.g., red phone)
More Challenges

Widespread use of ADSL and cable
modems
 today,
modems limit Internet use
 what if lots of TCP cheats?

Can we build a reliable, secure Internet?
 99%
uptime -> 99.999% uptime
 spoofing, denial of service, ...
Transport: Reliable, Efficient
Message Delivery
Simple network model
 Network measurement
 Stop and wait
 Sliding window

Simple network model
Network is a pipe connection two computers
Packets
Basic Metrics

Bandwidth, delay, overhead, error rate and
message size
Network metrics

Bandwidth


Delay or Latency


takes O secs for CPU to put message on wire
Error rate


Takes D seconds for bit to progagate down wire
Overhead


Data transmitted at a rate of R bits/sec
Probability P that messsage will not arrive intact
Message size

Size M of data being transmitted
How long to send a message?

Transmit time T = M/R + D
 10Mbps
Ethernet LAN (M=1KB)
– M/R=1ms, D ~=5us
 155Mbps
cross country ATM (M=1KB)
– M/R = 50us, D ~= 40-100ms

R*D is “storage” of pipe
How to measure bandwidth?
Measure how slow link increases gap
between packets
Slow bottleneck link
How to measure delay?
Measure round-trip time
start
stop
How to measure error rate?
Measure number of packets
acknowledged
Packet
dropped
Slow bottleneck link
Reliable transmission
How to send a packet reliably when it
can be lost?
 Two mechanisms

 Acknowledgements
 Timeouts

Simplest reliable protocol: Stop and Wait
Stop and Wait
Send a packet, stop and wait until
acknowledgement arrives
Time
Timeout
Sender
Receiver
ACK lost
Timeout
Timeout
Timeout
Timeout
Timeout
Time
Timeout
Recovering from error
Packet lost
Early timeout
Problems with Stop and Wait

How to recognize a duplicate
transmission?
 Put

sequence number in packet
Performance
 Unless
R*D is very small, the sender can’t
fill the pipe
 Solution: sliding window protocols