host - university of michigan
TRANSCRIPT
![Page 1: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/1.jpg)
1
Z. Morley Mao
EECS589: Advanced Computer Networks
http://eecs.umich.edu/courses/eecs589
The Host!
Getting Started…!
“Division of Labor” in Today’s Internet:
IP as the Host/Network Interface
2
![Page 2: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/2.jpg)
2
3
Host-Network Division of Labor!
• Packet switching – Divide messages into a sequence of packets – Headers with source and destination address
• Best-effort delivery – Packets may be lost – Packets may be corrupted – Packets may be delivered out of order
host host
network
4
Host-Network Interface: Why Packets?!
• Data traffic is bursty – Logging in to remote machines – Exchanging e-mail messages
• Don’t want to waste bandwidth – No traffic exchanged during idle periods
• Better to allow multiplexing – Different transfers share access to same links
• Packets can be delivered by most anything – RFC 1149: IP Datagrams over Avian Carriers
![Page 3: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/3.jpg)
3
5
Host-Network Interface: Why Best-Effort?!
• Never having to say you’re sorry… – Don’t reserve bandwidth and memory – Don’t do error detection & correction – Don’t remember from one packet to next
• Easier to survive failures – Transient disruptions are okay during failover
• Can run on nearly any link technology – Greater interoperability and evolution
6
Intermediate Transport Layer!• But, applications want efficient, accurate
transfer of data in order, in a timely fashion – Let the end hosts handle all of that – (An example of the “end-to-end argument”)
• Transport layer can optionally… – Retransmit lost packets – Put packets back in order – Detect and handle corrupted packets – Avoid overloading the receiver – <insert your requirement here>
![Page 4: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/4.jpg)
4
IP Suite: End Hosts vs. Routers!
7
HTTP
TCP
IP
Ethernet interface
HTTP
TCP
IP
Ethernet interface
IP IP
Ethernet interface
Ethernet interface
SONET interface
SONET interface
host host
router router
HTTP message
TCP segment
IP packet IP packet IP packet
The “Narrow Waist” of IP!
8
UDP TCP
Data Link
Physical
Applications
The Hourglass Model
Waist
The waist facilitates interoperability
FTP HTTP TFTP NV
TCP UDP
IP
NET1 NET2 NETn …
![Page 5: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/5.jpg)
5
Layer Encapsulation!
9
Get index.html
Connection ID
Source/Destination
Link Address
User A User B
But What About the Inside of the Network!
“Division of Labor” Between Network Elements and the Management System
10
![Page 6: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/6.jpg)
6
Inside the Network!
11 Forward packets from the sender to the receiver!
Split into Data vs. Control Plane!• Data plane: packets
– Handle individual packets as they arrive – Forward, drop, or buffer – Mark, shape, schedule, …
• Control plane: events – Track changes in network topology – Compute paths through the network – Reserve resources along a path
12 Motivated by need for high-speed packet forwarding!
![Page 7: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/7.jpg)
7
Adding the Management Plane !• Making the network run well
– Traffic reaches the right destination – Traffic flows over short, uncongested paths – Unwanted traffic is discarded – Failure recovery happens quickly – Routers don’t run out of resources
• A control loop with the network – Measure (sense): topology,
traffic, performance, … – Control (actuate): configure
control and data planes
13
Next Three Classes: Review!• Host
– Network discovery and bootstrapping – Resource allocation and interface to applications
• Control plane – Distributed algorithms for computing paths – Disseminating the addresses of end hosts
• Data plane – Streaming algorithms and switch fabric – Forward, filter, buffer, schedule, mark, monitor, …
• In addition, we will cover some research papers.
14
![Page 8: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/8.jpg)
8
Problems Lurking!
Challenges Tied to Early Design Decisions!
• Power of programmable end hosts – Easy to spoof IP addresses, e-mail addresses, … – Incentives for users to violate congestion control – Malicious users launching Denial-of-Service attacks
• Best-effort packet-delivery service – Inefficient in high-loss environments (wireless) – Poor performance for interactive applications – Expensive per-packet handling on high-speed links
![Page 9: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/9.jpg)
9
Challenges Tied to Early Design Decisions!
• Layering and the IP narrow waist – Low efficiency due to many layers of headers – Poor visibility into underlying shared risks – Complex network management due to multiple
interconnected protocols and systems
• Decentralized control – Hierarchical addressing makes mobility difficult, and
requires careful configuration – Autonomy makes measurement (and troubleshooting
and accountability) hard – Autonomy makes protocol changes difficult
Recurring Challenges!• Security
– Weak notions of identity that are easy to spoof – Protocols that rely on good behavior – Incomplete or non-existent registries, keys, …
• Mobility and disconnected operation – Hierarchical addressing closely tied with routing – Presumption that hosts are connected
• Network management – Many coupled, decentralized control loops – Limited visibility into across layers and networks
• Application performance requirements – Real-time, interactive applications – Throughput sensitive vs. delay-sensitive
![Page 10: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/10.jpg)
10
Internet is Not Standing Still!• Partial solutions to these problems
– Often as “add ons” or “extensions” – Hampered by need to be backwards compatible, and
work when only partially deployed – Rather than complete architectural solutions
• Solutions create problems of their own – Violations of architectural assumptions – Unexpected interactions with applications – Adding complexity to an already complex system
Example: Middleboxes!• Middleboxes are intermediaries
– Interposed in-between the communicating hosts – Often without knowledge of one or both parties
• Examples – Network address translators – Firewalls – Traffic shapers – Intrusion detection systems – Transparent Web proxy caches – Application accelerators
![Page 11: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/11.jpg)
11
Middleboxes Address Practical Challenges!• Host mobility
– Relaying traffic to a host in motion
• IP address depletion – Allowing multiple hosts to share a single address
• Security concerns – Discarding suspicious or unwanted packets – Detecting suspicious traffic
• Performance concerns – Controlling how link bandwidth is allocated – Storing popular content near the clients
Middleboxes Violate Network-Layer Principles!
• Globally unique identifiers – Each node has a unique, fixed IP address – … reachable from everyone and everywhere
• Simple packet forwarding – Network nodes simply forward packets – … rather than modifying or filtering them
source! destination!
IP network
![Page 12: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/12.jpg)
12
Two Views of Middleboxes!• An abomination
– Violation of layering – Cause confusion in reasoning about the network – Responsible for many subtle bugs
• A practical necessity – Solving real and pressing problems – Needs that are not likely to go away
• Would they arise in any edge-empowered network, even if redesigned from scratch?
Clean-Slate Network Architecture!• Clean-slate architecture
– Without constraints of today’s artifacts – To have a stronger intellectual foundation – And move beyond the incremental fixes
• Still, some constraints inevitably remain – Ignore today’s artifacts, but not necessarily all reality
• Such as… – Resource limitations (CPU, memory, bandwidth) – Time delays between nodes – Independent economic entities – Malicious parties – The need to evolve over time
![Page 13: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/13.jpg)
13
Conclusions!
• Internet architecture is a huge success – Functionality at programmable edge nodes – Best-effort packet-delivery service – Layering and the IP hourglass model – Decentralized control of the global system
• These very features are causing problems – Security, mobility, manageability, performance, reliability,
…
• Rethinking the network architecture – For a strong intellectual foundation – And long-term improvements to the Internet
Host-Network Division of Labor!
26
• Network – Best-effort packet delivery – Between two (or more) end-point addresses
• Hosts – Everything else
host host
network
![Page 14: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/14.jpg)
14
The Role of the End Host!• Network discovery and bootstrapping
– How does the host join the network? – How does the host get an address?
• Interface to networked applications – What interface to higher-level applications? – How does the host realize that abstraction?
• Distributed resource sharing – What roles does the host play in network
resource allocation decisions?
27
Network Discovery and Bootstrapping!
28
![Page 15: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/15.jpg)
15
Three Kinds of Identifiers!Host Name IP Address MAC Address
Example www.cs.umich.edu 141.212.113.143 00-15-C5-49-04-A9
Size Hierarchical, human readable, variable length
Hierarchical, machine readable, 32 bits (in IPv4)
Flat, machine readable, 48 bits
Read by Humans, hosts IP routers Switches in LAN
Allocation, top-level
Domain, assigned by registrar (e.g., for .edu)
Variable-length prefixes, assigned by ICANN, RIR, or ISP
Fixed-sized blocks, assigned by IEEE to vendors (e.g., Dell)
Allocation, low-level
Host name, local administrator
Interface, by admin or DHCP
Interface, by vendor
29
Learning a Host’s Address!
• Who am I? – Hard-wired: MAC address – Static configuration: IP interface configuration – Dynamically learned: IP address configured by DHCP
• Who are you? – Hard-wired: IP address in a URL, or in the code – Dynamically looked up: ARP or DNS
30
me! you!adapter! adapter!
![Page 16: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/16.jpg)
16
Mapping Between Identifiers!• Dynamic Host Configuration Protocol (DHCP)
– Given a MAC address, assign a unique IP address – … and tell host other stuff about the Local Area Network – To automate the boot-strapping process
• Address Resolution Protocol (ARP) – Given an IP address, provide the MAC address – To enable communication within the Local Area Network
• Domain Name System (DNS) – Given a host name, provide the IP address – Given an IP address, provide the host name
31
Dynamic Host Configuration Protocol!
32
arriving client! DHCP server!
DHCP discover!(broadcast)!
DHCP offer!
DHCP request!
DHCP ACK!
(broadcast)!
Host learns IP address,!Subnet mask, Gateway address, DNS server(s), and a lease time.!
![Page 17: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/17.jpg)
17
Address Resolution Protocol (ARP)!• Every host maintains an ARP table
– (IP address, MAC address) pair
• Consult the table when sending a packet – Map destination IP address to destination MAC address – Encapsulate and transmit the data packet
• But, what if the IP address is not in the table? – Sender broadcasts: “Who has IP address 1.2.3.156?” – Receiver responds: “MAC address 58-23-D7-FA-20-B0” – Sender caches the result in its ARP table
33
Domain Name System!
Host at cis.poly.edu wants IP address for gaia.cs.umass.edu
34
requesting host cis.poly.edu
gaia.cs.umass.edu
root DNS server
local DNS server dns.poly.edu
1
2 3
4 5
6
authoritative DNS server dns.cs.umass.edu
7 8
TLD DNS server
Recursive query: #1!Iterative queries: #2, 4, 6!
![Page 18: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/18.jpg)
18
Questions!• Should addresses correspond to the interface
(point of attachment) or to the host?
• Why do we have all three identifiers? Do we need all three?
• What should be done to prevent spoofing of addresses?
35
Interface to Applications!
36
![Page 19: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/19.jpg)
19
Socket Abstraction!• Best-effort packet delivery is a clumsy abstraction
– Applications typically want higher-level abstractions – Messages, uncorrupted data, reliable in-order delivery
• Applications communicate using “sockets” – Stream socket: reliable stream of bytes (like a file) – Message socket: unreliable message delivery 37
socket! socket!
User process! User process!
Operating!System!
Operating!System!
Two Basic Transport Features!• Demultiplexing: port numbers
• Error detection: checksums
38
Web server!(port 80)!
Client host!
Server host 128.2.194.242!
Echo server!(port 7)!
Service request for!128.2.194.242:80!
(i.e., the Web server)!OS!Client!
IP! payload!
detect corruption!
![Page 20: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/20.jpg)
20
Two Main Transport Layers!• User Datagram Protocol (UDP)
– Just provides demultiplexing and error detection – Header fields: port numbers, checksum, and length – Low overhead, good for query/response and multimedia
• Transmission Control Protocol (TCP) – Adds support for a “stream of bytes” abstraction – Retransmitting lost or corrupted data – Putting out-of-order data back in order – Preventing overflow of the receiver buffer – Adapting the sending rate to alleviate congestion – Higher overhead, good for most stateful applications
39
Questions!• Is a socket between two IP addresses the right
abstraction? – Mobile hosts? – Replicated services?
• What does the network know about the traffic? – Inferring the application from the port numbers?
• Is end-to-end error detection and correction the right model? – High loss environments? – Expense of retransmitting over the entire path?
40
![Page 21: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/21.jpg)
21
Distributed Resource Sharing!
41
Resource Allocation Challenges!• Best-effort network easily becomes overloaded
– No mechanism to “block” excess calls – Instead excess packets are simply dropped
• Examples – Shared Ethernet medium: frame collisions – Ethernet switches and IP routers: full packet buffers
• Quickly leads to congestion collapse
42 Load
Goodput “congestion!collapse”! Increase in load that
results in a decrease in useful work done.
![Page 22: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/22.jpg)
22
End Hosts Adjusting to Congestion!• End hosts adapt their sending rates
– In response to network conditions
• Learning that the network is congested – Shared Ethernet: carrier sense multiple access
! Seeing your own frame collide with others – IP network: observing your end-to-end performance
! Packet delay or loss over the end-to-end path
• Adapting to congestion – Slowing down the sending rate, for the greater good – But, host doesn’t know how bad things might be…
43
Ethernet Back-off Mechanism!
• Carrier sense: wait for link to be idle – If idle, start sending; if not, wait until idle
• Collision detection: listen while transmitting – If collision: abort transmission, and send jam signal
• Exponential back-off: wait before retransmitting – Wait random time, exponentially larger on each retry 44
![Page 23: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/23.jpg)
23
TCP Congestion Control!• Additive increase, multiplicative decrease
– On packet loss, divide congestion window in half – On success for last window, increase window linearly
45
t
Window
halved
Loss
Other mechanisms: slow start, fast retransmit vs. timeout loss, etc. !
Questions!• What role should the network play in resource
allocation? – Explicit feedback to the end hosts? – Enforcing an explicit rate allocation?
• What is a good definition of fairness?
• What about hosts who cheat to hog resources? – How to detect cheating? How to prevent/punish?
• What about wireless networks? – Difficulty of detecting collisions (due to fading) – Loss caused by interference, not just congestion
46
![Page 24: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/24.jpg)
24
“A Protocol for Packet Network Intercommunication”
(IEEE Trans. on Communications, May 1974)"Vint Cerf and Bob Kahn
Written when Vint Cerf was an assistant professor at Stanford, and Bob Kahn was working at ARPA. !
Life in the 1970s…!• Multiple unconnected networks
– ARPAnet, data-over-cable, packet satellite (Aloha), packet radio, …
• Heterogeneous designs – Addressing, max packet size, handling of lost/
corrupted data, fault detection, routing, …
48 ARPAnet satellite net
![Page 25: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/25.jpg)
25
Handling Heterogeneity!• Where to handle heterogeneity?
– Application process? End hosts? Packet switches?
• Compatible process and host conventions – Obviate the need to support all combinations
• Retain the unique features of each network – Avoid changing the local network components
• Introduce the notion of a gateway
49
Internetwork Layer and Gateways!Internetwork Layer • Internetwork appears as
a single, uniform entity • Despite the heterogeneity
of the local networks • Network of networks
Gateway • “Embed internetwork
packets in local packet format or extract them”
• Route (at internetwork level) to next gateway
50 ARPAnet satellite net
gateway
![Page 26: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/26.jpg)
26
Internetwork Packet Format!
• Internetwork header in standard format – Interpreted by the gateways and end hosts
• Source and destination addresses – Uniformly and uniquely identify every host
• Ensure proper sequencing of the data – Include a sequence number and byte count
• Enable detection of corrupted text – Checksum for an end-to-end check on the text
51
local header
text checksum source address
dest. address
seq. #
byte count
flag field
internetwork header!
Process-Level Communication!• Enable pairs of processes to communicate
– Full duplex – Unbounded but finite-length messages – E.g., keystrokes or a file
• Key ideas – Port numbers to (de)multiplex packets – Breaking messages into segments – Sequence numbers and reassembly – Retransmission and duplicate detection – Window-based flow control
52
![Page 27: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/27.jpg)
27
Discussion!• What did they get right?
– Which ideas were key to the Internet’s success? – Which decisions still seem right today?
• What did they miss? – Which ideas had to be added later? – Which decisions seem wrong in hindsight?
• What would you do in a clean-slate design? – If your goal wasn’t to support communication
between disparate packet-switched networks – Would you do anything differently?
53
“End-to-End Arguments in System Design”
(ACM Trans. on Computer Systems, November 1984)"J. Saltzer, D. Reed, and D. Clark
![Page 28: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/28.jpg)
28
End-to-End Argument!• Operations should occur only at the end points
• … unless needed for performance optimization
55
2 4
5 3 1
Many things can go wrong: disk errors, software errors, hardware errors, communication errors, …!
Trade-Offs!• Put functionality at each hop
– All applications pay the price – End systems still need to check for errors
• Place functionality only at the ends – Slower error detection – End-to-end retransmission wastes bandwidth
• Compromise solution? – Reliable end-to-end transport protocol (TCP) – Plus file checksums to detect file-system errors
56
![Page 29: Host - University of Michigan](https://reader034.vdocument.in/reader034/viewer/2022042620/62646ecaa229f009f402e2e9/html5/thumbnails/29.jpg)
29
Discussion!• When should the network support a function
anyway? – E.g., link-layer retransmission in wireless networks?
• Whose interests are served by the e2e argument?
• How does a network operator influence the network without violating the e2e argument?
• Does the design of IP and TCP make it *hard* to violate the e2e argument? – E.g., middlebox functionality like NATs, firewalls, proxies
• Should the e2e argument apply to routing? 57