1. EE122: Potpourri
November 24, 2003

2. EECS 122: Introduction to Computer Networks Various Topics
Computer Science Division
Department of Electrical Engineering and Computer Sciences
University of California, Berkeley
Berkeley, CA

3. Outline Address Resolution Protocol (ARP)
Dynamic Host Configuration Protocol (DHCP)
Internet Control Message Protocol (ICMP)
Network measurements
End-to-end arguments and layering
4/8/ :50 AM

4. 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?
4/8/ :50 AM

5. 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?
4/8/ :50 AM

6. 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
4/8/ :50 AM

7. Assumptions in ARP Assumes that physical network can broadcast
Not always true: e.g., ATM
Must find methods for these networks
(e.g., ATMARP)
4/8/ :50 AM

8. 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
4/8/ :50 AM

9. 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)
4/8/ :50 AM

10. Methods of Address Assignment
Have DHCP database that matches MAC address with IP address
Freely assign IP addresses from pool
4/8/ :50 AM

11. 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
4/8/ :50 AM

12. 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!
4/8/ :50 AM

13. 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.
4/8/ :50 AM

14. How Can We Measure? Passive Measurements Active Measurements
4/8/ :50 AM

15. Passive Measurements Packet traces Flow statistics
tcpdump, etc.
requires physical access to link
lots(!!) of data
Flow statistics
cisco’s Netflow
Backscatter analysis
Honeypots
4/8/ :50 AM

16. 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
4/8/ :50 AM

17. 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
4/8/ :50 AM

18. Active Measurements Ping: Traceroute: Pathchar (and others):
4/8/ :50 AM

19. Ping Uses ICMP “echo” feature
PING llama.icir.org ( ): 56 data bytes
64 bytes from : icmp_seq=0 ttl=47 time= ms
64 bytes from : icmp_seq=1 ttl=47 time= ms
64 bytes from : icmp_seq=2 ttl=47 time= ms
64 bytes from : icmp_seq=3 ttl=47 time= ms
64 bytes from : icmp_seq=4 ttl=47 time= ms
64 bytes from : icmp_seq=5 ttl=47 time=25.97 ms
64 bytes from : icmp_seq=6 ttl=47 time=26.5 ms
64 bytes from : icmp_seq=7 ttl=47 time= ms
64 bytes from : icmp_seq=8 ttl=47 time= ms
64 bytes from : icmp_seq=9 ttl=47 time= ms
--- llama.icir.org ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 25.97/29.228/ ms
4/8/ :50 AM

20. Ping
Ping can help measure:
delays
loss
reachability
4/8/ :50 AM

21. 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
4/8/ :50 AM

22. Traceroute
traceroute to llama.icir.org ( ), 30 hops max, 40 byte packets
1 adsl dsl.snfc21.pacbell.net ( ) ms ms ms
2 dist2-vlan60.snfc21.pbi.net ( ) ms ms ms
3 bb1-g8-1.snfc21.pbi.net ( ) ms ms ms
4 bb2-p3-0.snfcca.sbcglobal.net ( ) ms ms ms
5 ex1-p12-0.pxpaca.sbcglobal.net ( ) ms ms ms
6 as4006-cogent.pxpaca.sbcglobal.net ( ) ms ms ms
7 p13-0.core02.sfo01.atlas.cogentco.com ( ) ms ms ms
8 cenic.demarc.cogentco.com ( ) ms ms ms
9 inet-svl-m10.cenic.net ( ) ms ms ms
10 inet-ucb--svl-isp.cenic.net ( ) ms ms ms
11 vlan193.inr-201-eva.berkeley.edu ( ) ms ms ms
12 fast4-0-0.inr-667-eva.berkeley.edu ( ) ms ms ms
13 router2-fast0-0-0.icsi.berkeley.edu ( ) ms ms ms
14 llama.icir.org ( ) ms ms ms
4/8/ :50 AM

23. Traceroute
Use TTL and ICMP
4/8/ :50 AM

24. Traceroute Can help determine routing behavior path stability topology
4/8/ :50 AM

25. Measurement Surprises
Self-similarity traffic structure
Power-law topologies
4/8/ :50 AM

26. 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
4/8/ :50 AM

27. Self-Similarity
4/8/ :50 AM

28. Explanation Flow arrival: Poisson Flow length: heavy-tailed
most flows are very short
but most bytes are in long flows
4/8/ :50 AM

29. 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
4/8/ :50 AM

30. What You Need to Know ARP DHCP ICMP (ttl=0) Measurement tools
ping, traceroute
backscatter, honeypots
Review to follow....
4/8/ :50 AM

31. 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, , web, P2P, etc.
How do we organize this mess?
4/8/ :50 AM

32. 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
4/8/ :50 AM

33. 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)
4/8/ :50 AM

34. 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
4/8/ :50 AM

35. Who Does What? Seven layers
Lower three layers are implemented everywhere
Next four layers are implemented only at hosts
Host A
Host B
Application
Application
Presentation
Presentation
Session
Session
Transport
Router
Transport
Network
Network
Network
Datalink
Datalink
Datalink
Physical
Physical
Physical
Physical medium
4/8/ :50 AM

36. Logical Communication
Layers interacts with corresponding layer on peer
Host A
Host B
Application
Application
Presentation
Presentation
Session
Session
Transport
Router
Transport
Network
Network
Network
Datalink
Datalink
Datalink
Physical
Physical
Physical
Physical medium
4/8/ :50 AM

37. Physical Communication
Communication goes down to physical network, then to peer, then up to relevant layer
Host A
Host B
Application
Application
Presentation
Presentation
Session
Session
Transport
Router
Transport
Network
Network
Network
Datalink
Datalink
Datalink
Physical
Physical
Physical
Physical medium
4/8/ :50 AM

38. 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
4/8/ :50 AM

39. OSI vs. Internet
OSI: conceptually define services, interfaces, protocols
Internet: provide a successful implementation IP
LAN
Packet
radio
TCP
UDP
Telnet
FTP
DNS
Application
Application
Presentation
Session
Transport
Transport
Network
Internet
Datalink
Net access/
Physical
Physical
OSI (formal)
Internet (informal)
4/8/ :50 AM

40. 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
4/8/ :50 AM

41. Multiple Instantiations of Layers
4/8/ :50 AM

42. 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 IP
LAN
Packet
radio
TCP
UDP
Telnet
FTP
DNS
Application
Transport
Internet
Net access/
Physical
4/8/ :50 AM

43. Hourglass
4/8/ :50 AM

44. 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
4/8/ :50 AM

45. Network Modularity Two crucial decisions Layers, not just modules
alternatives?
Single internetworking layer, not multiple
4/8/ :50 AM

46. Placing Functionality
“End-to-End Arguments in System Design” by Saltzer, Reed, and Clark
4/8/ :50 AM

47. 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
4/8/ :50 AM

48. 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
4/8/ :50 AM

49. 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
4/8/ :50 AM

50. 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
4/8/ :50 AM

51. 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
4/8/ :50 AM

52. 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
4/8/ :50 AM

53. 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
4/8/ :50 AM

54. 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...
4/8/ :50 AM