EE122: Potpourri
November 24, 2003
Katz, Stoica F04
EECS 122:
Introduction to Computer Networks
Various Topics
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley
Berkeley, CA 94720-1776
Katz, Stoica F04
Outline

Address Resolution Protocol (ARP)

Dynamic Host Configuration Protocol (DHCP)

Internet Control Message Protocol (ICMP)

Network measurements

End-to-end arguments and layering
6/27/2016 7:55 PM
Katz, Stoica F04
3
Address Resolution Protocol (ARP)

Question: how do packets actually get to their
destination?

IP routing tables: based on network addresses

Ethernet physical interfaces only understand
ethernet addresses

So, how do packets actually reach their
destination?
6/27/2016 7:55 PM
Katz, Stoica F04
4
Address Mappings

Each host keeps a mapping table:
- IP address <-> physical network address

When a machine on a physical network wants to
reach another host on the same physical network
(either first-hop router, or another host), it
consults this table

How is this table maintained?
6/27/2016 7:55 PM
Katz, Stoica F04
5
ARP

When the table doesn’t have the required
mapping, the host broadcasts a message (to the
physical net) asking: who has this IP address?

The appropriate host responds with its physical
address (and inserts the requester in its table)

All others listening who have either host in their
table refresh their entries
6/27/2016 7:55 PM
Katz, Stoica F04
6
Assumptions in ARP

Assumes that physical network can broadcast

Not always true: e.g., ATM

Must find methods for these networks
- (e.g., ATMARP)
6/27/2016 7:55 PM
Katz, Stoica F04
7
Host Configuration

How does a host know its IP address?

Manually configured:
- time consuming
- doesn’t work for transient hosts

Dynamic Host Configuration Protocol (DHCP)
- much easier to administer
- allows transient hosts to automatically configure
themselves
6/27/2016 7:55 PM
Katz, Stoica F04
8
DHCP

New host broadcasts DHCPDiscover message
- Using IP broadcast

If DHCP server is local, it responds

If no DHCP server is local, there is a DHCP relay
agent which forwards DHCPDiscover messages
to DHCP server

DHCP server gives IP address (and other info)
6/27/2016 7:55 PM
Katz, Stoica F04
9
Methods of Address Assignment

Have DHCP database that matches MAC
address with IP address

Freely assign IP addresses from pool
6/27/2016 7:55 PM
Katz, Stoica F04 10
Internet Control Message Protocol

ICMP provides for a variety of control messages
-
host unreachable
reassembly process failed
TTL reached 0
IP header checksum failed
ICMP redirect
6/27/2016 7:55 PM
Katz, Stoica F04
11
Network Measurement

Internet is huge and complex
- O(100M) hosts, O(1M) routers, O(10K) networks
- Myriad of interacting protocols
- Fast pace of change

How can we understand what is really going on?

Take measurements!
6/27/2016 7:55 PM
Katz, Stoica F04 12
What Can We Measure?

Structure: topology, link characteristics, etc.

Traffic: traffic characteristics, etc.

Users and Applications: use of various apps

Failures: prevalence of losses, outages, etc.

Nefarious behavior: DoS attacks, scans, etc.
6/27/2016 7:55 PM
Katz, Stoica F04 13
How Can We Measure?

Passive Measurements

Active Measurements
6/27/2016 7:55 PM
Katz, Stoica F04 14
Passive Measurements

Packet traces
- tcpdump, etc.
- requires physical access to link
- lots(!!) of data

Flow statistics
- cisco’s Netflow

Backscatter analysis

Honeypots
6/27/2016 7:55 PM
Katz, Stoica F04 15
Backscatter

Most Denial-of-Service attacks involved randomly
chosen forged source addresses

The victim typically replies to these packets
- they appear to be normal TCP SYNs

Thus, the “backscatter” from DoS attacks results
in traffic being sent to random hosts

If one monitors the traffic to some unoccupied
address range, this backscatter can be measured
6/27/2016 7:55 PM
Katz, Stoica F04 16
Honeypots

Hosts that have no useful purpose
- i.e., there is no reason one would contact them for
legitimate reasons

They monitor all activity, noting the nature of
attacks

Provide useful data for prevalence and method of
attacks
6/27/2016 7:55 PM
Katz, Stoica F04 17
Active Measurements

Ping:

Traceroute:

Pathchar (and others):
6/27/2016 7:55 PM
Katz, Stoica F04 18
Ping

Uses ICMP “echo” feature
PING llama.icir.org (192.150.187.22): 56
64 bytes from 192.150.187.22: icmp_seq=0
64 bytes from 192.150.187.22: icmp_seq=1
64 bytes from 192.150.187.22: icmp_seq=2
64 bytes from 192.150.187.22: icmp_seq=3
64 bytes from 192.150.187.22: icmp_seq=4
64 bytes from 192.150.187.22: icmp_seq=5
64 bytes from 192.150.187.22: icmp_seq=6
64 bytes from 192.150.187.22: icmp_seq=7
64 bytes from 192.150.187.22: icmp_seq=8
64 bytes from 192.150.187.22: icmp_seq=9
data bytes
ttl=47 time=53.116 ms
ttl=47 time=27.444 ms
ttl=47 time=26.758 ms
ttl=47 time=26.799 ms
ttl=47 time=26.092 ms
ttl=47 time=25.97 ms
ttl=47 time=26.5 ms
ttl=47 time=26.309 ms
ttl=47 time=26.875 ms
ttl=47 time=26.422 ms
--- llama.icir.org ping statistics --10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 25.97/29.228/53.116 ms
6/27/2016 7:55 PM
Katz, Stoica F04 19
Ping

Ping can help measure:
- delays
- loss
- reachability
6/27/2016 7:55 PM
Katz, Stoica F04 20
Packet Dispersion Techniques

Pathchar, etc., try to measure link bandwidth

Send two packets back-to-back

Delay between them “should” reflect minimal
bandwidth along path
6/27/2016 7:55 PM
Katz, Stoica F04 21
Traceroute
traceroute to llama.icir.org (192.150.187.22), 30 hops max, 40 byte packets
1 adsl-67-114-184-1.dsl.snfc21.pacbell.net (67.114.184.1) 12.002 ms 9.647 ms 9.638 ms
2 dist2-vlan60.snfc21.pbi.net (216.102.187.131) 10.006 ms 9.665 ms 9.773 ms
3 bb1-g8-1.snfc21.pbi.net (216.102.176.193) 10.783 ms 9.944 ms 10.205 ms
4 bb2-p3-0.snfcca.sbcglobal.net (151.164.190.186) 10.17 ms 10.339 ms 10.49 ms
5 ex1-p12-0.pxpaca.sbcglobal.net (216.102.176.234) 11.006 ms 11.29 ms 11.169 ms
6 as4006-cogent.pxpaca.sbcglobal.net (151.164.89.154) 11.452 ms 11.476 ms 11.588 ms
7 p13-0.core02.sfo01.atlas.cogentco.com (154.54.1.253) 11.593 ms 12.538 ms 12.5 ms
8 cenic.demarc.cogentco.com (38.112.6.226) 12.52 ms 11.859 ms 11.975 ms
9 inet-svl-m10.cenic.net (137.164.22.99) 12.359 ms 12.917 ms 12.968 ms
10 inet-ucb--svl-isp.cenic.net (137.164.24.106) 13.904 ms 13.605 ms 14.16 ms
11 vlan193.inr-201-eva.berkeley.edu (128.32.0.74) 14.769 ms 15.161 ms 15.577 ms
12 fast4-0-0.inr-667-eva.berkeley.edu (128.32.0.99) 26.077 ms 25.322 ms 25.013 ms
13 router2-fast0-0-0.icsi.berkeley.edu (169.229.0.30) 23.844 ms 23.844 ms 23.513 ms
14 llama.icir.org (192.150.187.22) 46.369 ms 25.425 ms 24.849 ms
6/27/2016 7:55 PM
Katz, Stoica F04 22
Traceroute

Use TTL and ICMP
6/27/2016 7:55 PM
Katz, Stoica F04 23
Traceroute

Can help determine routing behavior
- path stability
- topology
6/27/2016 7:55 PM
Katz, Stoica F04 24
Measurement Surprises

Self-similarity traffic structure

Power-law topologies
6/27/2016 7:55 PM
Katz, Stoica F04 25
Traffic Characteristics

Look at traffic on link as function of time,
measured over time intervals of size S

As S increases, we would expect traffic variations
to smooth out

Certainly if traffic was Poisson, this would be true
6/27/2016 7:55 PM
Katz, Stoica F04 26
Self-Similarity
6/27/2016 7:55 PM
Katz, Stoica F04 27
Explanation

Flow arrival: Poisson

Flow length: heavy-tailed
- most flows are very short
- but most bytes are in long flows
6/27/2016 7:55 PM
Katz, Stoica F04 28
Network Topology

Look at network graph (at AS or router level)

Consider the “degree distribution”
- number of edges connected to each node

This degree distribution is heavy-tailed
- most nodes have few connections
- but a few have very many connections
6/27/2016 7:55 PM
Katz, Stoica F04 29
What You Need to Know




ARP
DHCP
ICMP (ttl=0)
Measurement tools
- ping, traceroute
- backscatter, honeypots

Review to follow....
6/27/2016 7:55 PM
Katz, Stoica F04 30
Internet Architecture Revisited

Many different network styles and technologies
- circuit-switched vs packet-switched, etc.
- wireless vs wired vs optical, etc.

Many different applications
- ftp, email, web, P2P, etc.

How do we organize this mess?
6/27/2016 7:55 PM
Katz, Stoica F04 31
Software Modularity
Break system into modules:

Well-defined interfaces gives flexibility
- can change implementation of modules
- can extend functionality of system by adding new
modules

Interfaces hide information
- allows for flexibility
- but can hurt performance
6/27/2016 7:55 PM
Katz, Stoica F04 32
Network Modularity
Like software modularity, but with a twist:

Implementation distributed across routers and
hosts

Must decide both:
- how to break system into modules (layering)
- where modules are implemented (E2E argument)
6/27/2016 7:55 PM
Katz, Stoica F04 33
Layering

Layering is a particular form of modularization

The system is broken into a vertical hierarchy of
logically distinct entities (layers)

The service provided by one layer is based solely
on the service provided by layer below

Rigid structure: easy reuse, performance suffers
6/27/2016 7:55 PM
Katz, Stoica F04 34
Who Does What?

Seven layers
- Lower three layers are implemented everywhere
- Next four layers are implemented only at hosts
Host A
Application
Presentation
Session
Transport
Network
Datalink
Physical
Host B
Router
Network
Datalink
Physical
Physical medium
Application
Presentation
Session
Transport
Network
Datalink
Physical
6/27/2016 7:55 PM
Katz, Stoica F04 35
Logical Communication

Layers interacts with corresponding layer on peer
Host A
Application
Presentation
Session
Transport
Network
Datalink
Physical
Host B
Router
Network
Datalink
Physical
Physical medium
Application
Presentation
Session
Transport
Network
Datalink
Physical
6/27/2016 7:55 PM
Katz, Stoica F04 36
Physical Communication

Communication goes down to physical network, then
to peer, then up to relevant layer
Host A
Application
Presentation
Session
Transport
Network
Datalink
Physical
Host B
Router
Network
Datalink
Physical
Physical medium
Application
Presentation
Session
Transport
Network
Datalink
Physical
6/27/2016 7:55 PM
Katz, Stoica F04 37
Encapsulation


A layer can use only the service provided by the layer
immediate below it
Each layer may change and add a header to data packet
data
data
data
data
data
data
data
data
data
data
data
data
data
data
6/27/2016 7:55 PM
Katz, Stoica F04 38
OSI vs. Internet


OSI: conceptually define services, interfaces, protocols
Internet: provide a successful implementation
Application
Presentation
Session
Transport
Network
Datalink
Physical
OSI (formal)
Application
Transport
Internet
Net access/
Physical
Telnet
FTP DNS
TCP
UDP
IP
LAN
Packet
radio
Internet (informal)
6/27/2016 7:55 PM
Katz, Stoica F04 39
Multiple Instantiations

Can have several instantiations for each layer
- many applications
- many network technologies
- transport can be reliable (TCP) or not (UDP)

Applications dictate transport
- In general, higher layers can dictate lower layer

But this is a disaster!
- applications that can only run certain networks
6/27/2016 7:55 PM
Katz, Stoica F04 40
Multiple Instantiations of Layers
6/27/2016 7:55 PM
Katz, Stoica F04 41
Solution
A universal Internet layer:
 Internet has only IP at the Internet layer
 Many options for modules above IP
 Many options for modules below IP
Application
Transport
Internet
Net access/
Physical
Telnet
FTP DNS
TCP
UDP
IP
LAN
Packet
radio
6/27/2016 7:55 PM
Katz, Stoica F04 42
Hourglass
6/27/2016 7:55 PM
Katz, Stoica F04 43
Implications of Hourglass
A single Internet layer module:

Allows all networks to interoperate
- all networks technologies that support IP can exchange
packets

Allows all applications to function on all networks
- all applications that can run on IP can use any network

Simultaneous developments above and below IP
6/27/2016 7:55 PM
Katz, Stoica F04 44
Network Modularity
Two crucial decisions

Layers, not just modules
- alternatives?

Single internetworking layer, not multiple
- alternatives?
6/27/2016 7:55 PM
Katz, Stoica F04 45
Placing Functionality

“End-to-End Arguments in System Design” by
Saltzer, Reed, and Clark
6/27/2016 7:55 PM
Katz, Stoica F04 46
Basic Observation

Some applications have end-to-end performance
requirements
- reliability, security, etc.

Implementing these in the network is very hard:
- every step along the way must be fail-proof

The hosts:
- can satisfy the requirement without the network
- can’t depend on the network
6/27/2016 7:55 PM
Katz, Stoica F04 47
Conclusion
Implementing this functionality in the network:
 Doesn’t reduce host implementation complexity
 Does increase network complexity
 Probably imposes delay and overhead on all
applications, even if they don’t need functionality

However, implementing in network can enhance
performance in some cases
- very lossy link
6/27/2016 7:55 PM
Katz, Stoica F04 48
Conservative Interpretation

“Don’t implement a function at the lower levels of
the system unless it can be completely
implemented at this level” (Peterson and Davie)

Unless you can relieve the burden from hosts,
then don’t bother
6/27/2016 7:55 PM
Katz, Stoica F04 49
Radical Interpretation

Don’t implement anything in the network that can
be implemented correctly by the hosts
- e.g., multicast

Make network layer absolutely minimal
- ignore performance issues
6/27/2016 7:55 PM
Katz, Stoica F04 50
Moderate Interpretation

Think twice before implementing functionality in
the network

If hosts can implement functionality correctly,
implement it a lower layer only as a performance
enhancement

But do so only if it does not impose burden on
applications that do not require that functionality
6/27/2016 7:55 PM
Katz, Stoica F04 51
Extended Version of E2E Argument

Don’t put application semantics in network
- Leads to loss of flexibility
- Cannot change old applications easily
- Cannot introduce new applications easily

Normal E2E argument: performance issue
- introducing more functionality imposes more overhead
- subtle issue, many tough calls (e.g., multicast)

Extended version:
- short-term performance vs long-term flexibility
6/27/2016 7:55 PM
Katz, Stoica F04 52
Reality

Layering and E2E Principle regularly violated:
- Firewalls
- Transparent caches
- Other middleboxes

Battle between architectural purity and
commercial pressures
- extremely important
- imagine a world where new apps couldn’t emerge
6/27/2016 7:55 PM
Katz, Stoica F04 53
Summary

Layering is a good way to organize networks

Unified Internet layer decouples apps from
networks

E2E argument encourages us to keep IP simple

Commercial realities threaten to undo all of this...
6/27/2016 7:55 PM
Katz, Stoica F04 54