CSE 561 – Internetworking David Wetherall [email protected] Spring 2000.
-
date post
21-Dec-2015 -
Category
Documents
-
view
218 -
download
2
Transcript of CSE 561 – Internetworking David Wetherall [email protected] Spring 2000.
djw // CS 561, Spring 2000 L4.2
This Lecture
• Cerf and Kahn on what became TCP/IP• Clark on why the Internet is the way it is
• Two very powerful papers!– On the money predictions from 25+ years ago– Internet philosophy that still permeates design
djw // CS 561, Spring 2000 L4.3
Cerf and Kahn, 1973
• The need for Internetworking • Focus is process-to-process communication• Several challenges from heterogeneous networks
• Different kinds of addressing• Different MTUs• Different delays• Data corruption/loss• Different routing/management indications• Accounting
djw // CS 561, Spring 2000 L4.4
Highlights of Solution
• Gateways and IP over everything• Common addressing• Ports • Standard packet header format• TCP sliding window strategy• Association establishment
djw // CS 561, Spring 2000 L4.5
Fragmentation Issue
• Different networks may have different frame limits (MTUs)– Ethernet 1.5K, FDDI 4.5K
• Don’t know if packet will be too big for path beforehand– IPv4: fragment on demand and
reassemble at destination– IPv6: network returns error
message so host can learn limit
R1
H4
H5
H3H2H1
Network 2 (Ethernet)
H6
Network 3 (FDDI)
Fragment?
djw // CS 561, Spring 2000 L4.6
Fragment Fields
• Fragments of one packet identified by (source, dest, frag id) triple– Make unique
• Offset gives start, length changed
• Flags are More Fragments (MF) Don’t Fragment (DF)
Version HLen TOS Length
Identifier for Fragments Flags Fragment Offset
TTL Protocol Checksum
Source Address
Destination Address
Options (variable) Pad(variable)
0 4 8 16 19 31
Data
djw // CS 561, Spring 2000 L4.7
Fragment Considerations
• Relating fragments to original datagram provides:– Tolerance of loss, reordering and duplication– Ability to fragment fragments
• Consequences of fragmentation:– Loss of any fragments causes loss of entire packet– Need to time-out reassembly when any fragments lost
djw // CS 561, Spring 2000 L4.8
Path MTU Discovery
• Path MTU is the smallest MTU along path– Packets less than this size don’t get fragmented
• Fragmentation is a burden for routers– We already avoid reassembling at routers– Avoid fragmentation too by having hosts learn path MTUs
• Hosts send packets, routers return error if too large– Hosts discover limits, can fragment at source– Reassembly at destination as before
• Learned lesson from IPv4, streamlined in IPv6
djw // CS 561, Spring 2000 L4.9
Network Host
7 24
0
Network Host
14 16
1 0
Network Host
21 8
1 1 0
IPv4 Address Formats
• 32 bits written in “dotted quad” notation, e.g., 18.31.0.135
Class A
Class B
Class C
djw // CS 561, Spring 2000 L4.10
IPv6 Address Format
• 128 bits written in 16 bit hexadecimal chunks• Still hierarchical, just more levels
SubscriberIDProviderIDRegistryID001 InterfaceIDSubnetID
djw // CS 561, Spring 2000 L4.11
An Aside – ICMP
• What happens when things go wrong?– Need a way to test/debug a large, widely distributed
system
• ICMP = Internet Control Message Protocol (RFC792)– Companion to IP – required functionality
• Used for error and information reporting:– Errors that occur during IP forwarding– Queries about the status of the network
djw // CS 561, Spring 2000 L4.12
ICMP Generation
source dest
ICMP IP packet
IP packet
Error duringforwarding!
djw // CS 561, Spring 2000 L4.13
Common ICMP Messages
• Destination unreachable– “Destination” can be host, network, port or protocol
• Redirect– To shortcut circuitous routing
• TTL Expired– Used by the “traceroute” program
• Echo request/reply– Used by the “ping” program
• ICMP messages include portion of IP packet that triggered the error (if applicable) in their payload
djw // CS 561, Spring 2000 L4.14
ICMP Restrictions
• The generation of error messages is limited to avoid cascades … error causes error that causes error!
• Don’t generate ICMP error in response to:– An ICMP error– Broadcast/multicast messages (link or IP level)– IP header that is corrupt or has bogus source address– Fragments, except the first
• ICMP messages are often rate-limited too.
djw // CS 561, Spring 2000 L4.15
Naming Processes/Services
• Process here is an abstract term for your Web browser (HTTP), Email servers (SMTP), hostname translation (DNS), RealAudio player (RTSP), etc.
• How do we identify for remote communication?– Process id or memory address are OS-specific and transient
…
• So TCP and UDP use Ports– 16-bit integers representing mailboxes that processes “rent”– Identify process uniquely as (IP address, protocol, port)
djw // CS 561, Spring 2000 L4.16
Picking Port Numbers
• We still have the problem of allocating port numbers– What port should a Web server use on host X?– To what port should you send to contact that Web server?
• Servers typically bind to “well-known” port numbers– e.g., HTTP 80, SMTP 25, DNS 53, … look in /etc/services– Ports below 1024 reserved for “well-known” services
• Clients use OS-assigned temporary (ephemeral) ports– Above 1024, recycled by OS when client finished
djw // CS 561, Spring 2000 L4.17
Options (variable)
Data
Checksum
SrcPort DstPort
HdrLen 0 Flags
UrgPtr
AdvertisedWindow
SequenceNum
Acknowledgment
0 4 10 16 31
TCP Header Format
• Sequence and Ack numbers used for the sliding window– Congestion control works by controlling the window size
djw // CS 561, Spring 2000 L4.18
Connection Establishment
• Both sender and receiver must be ready before we start to transfer the data– Sender and receiver need to agree on a set of
parameters, e.g., the Maximum Segment Size (MSS)
• This is signaling– It sets up state at the endpoints– Compare to “dialing” in the telephone network
• In TCP a Three-Way Handshake is used
djw // CS 561, Spring 2000 L4.19
Three-Way Handshake
• Opens both directions for transfer
Active participant(client)
Passive participant(server)
SYN, SequenceNum = x
SYN + ACK, SequenceNum = y,
ACK, Acknowledgment = y + 1
Acknowledgment = x + 1
+data
djw // CS 561, Spring 2000 L4.20
Some Comments
• We could abbreviate this setup, but it was chosen to be robust, especially against delayed duplicates– Three-way handshake from Tomlinson 1975
• Choice of changing initial sequence numbers (ISNs) minimizes the chance of hosts that crash getting confused by a previous incarnation of a connection
• But with random ISN it actually proves that two hosts can communicate– Weak form of authentication
djw // CS 561, Spring 2000 L4.21
Again, with States
Active participant(client)
Passive participant(server)
SYN, SequenceNum = x
SYN + ACK, SequenceNum = y,
ACK, Acknowledgment = y + 1
Acknowledgment = x + 1
+data
LISTEN
SYN_RCVD
SYN_SENT
ESTABLISHED
ESTABLISHED
djw // CS 561, Spring 2000 L4.22
Connection Teardown
• Orderly release by sender and receiver when done– Delivers all pending data and “hangs up”
• Cleans up state in sender and receiver
• TCP connection teardown follows, but first an aside …
djw // CS 561, Spring 2000 L4.23
The Two-Army Problem
• Yellow armies want to synchronize their attacks to win– But their messengers might be captured by the orange
army
Yellow Army Yellow Army
Orange Army
It is impossible for both Yellow armies guarantee a joint attack!
djw // CS 561, Spring 2000 L4.24
TCP Connection Teardown
• Symmetric close – both sides shutdown independently
Web server Web browser
FIN
ACK
ACK
FIN
FIN_WAIT_1
CLOSE_WAIT
LAST_ACKFIN_WAIT_2
TIME_WAIT
CLOSEDCLOSED
…
djw // CS 561, Spring 2000 L4.25
The TIME_WAIT State
• We wait 2MSL (two times the maximum segment lifetime of 60 seconds) before completing the close
• Why?
• ACK might have been lost and so FIN will be resent
• Could interfere with a subsequent connection
djw // CS 561, Spring 2000 L4.26
Flow Control
• Sender must transmit data no faster than it can be consumed by the receiver– Receiver might be a slow machine– App might consume data slowly
• Implement by adjusting the size of the sliding window used at the sender based on receiver feedback about available buffer space– This is the purpose of the Advertised Window field
djw // CS 561, Spring 2000 L4.27
Sending application
LastByteWritten
TCP
LastByteSentLastByteAcked
Receiving application
LastByteRead
TCP
LastByteRcvdNextByteExpected
Sender and Receiver Buffering
= available buffer = buffer in use
djw // CS 561, Spring 2000 L4.28
Example – Exchange of Packets
SEQ=1
SEQ=2
SEQ=3SEQ=4
ACK=2; WIN=3
ACK=3; WIN=2
ACK=4; WIN=1
ACK=5; WIN=0
Receiver has buffer of size 4 and application doesn’t readStall due to
flow control here
T=1
T=2
T=3
T=4
T=5
T=6
djw // CS 561, Spring 2000 L4.29
Example – Buffer at Sender
21 3 4 5 6 7 8 9
21 3 4 5 6 7 8 9
21 3 4 5 6 7 8 9
21 3 4 5 6 7 8 9
21 3 4 5 6 7 8 9
21 3 4 5 6 7 8 9
T=1
T=2
T=3
T=4
T=5
T=6
=acked
=sent
=advertised
djw // CS 561, Spring 2000 L4.30
Clark, 1988
• Design philosophy in retrospect• Several important themes
• Division into IP + TCP and UDP and QOS• Survivability and impact on where to store state
djw // CS 561, Spring 2000 L4.31
Contributions
• Fate-sharing• Flows and Soft-state
• These two plus the E2E argument (also Clark) define much of the architecture of the Internet
djw // CS 561, Spring 2000 L4.32
Shortcomings
• Some have become increasingly apparent today
• Punted on accounting• End host control at odds with robustness• Distributed management
djw // CS 561, Spring 2000 L4.33
Network Service Models
• Datagram delivery: postal service– Also connectionless, best-effort or unreliable service– Network can’t guarantee delivery of the packet– Each packet from a host is routed independently– Example: IP
• Virtual circuit models: telephone– Also connection-oriented service– Signaling: connection establishment, data transfer,
teardown– All packets from a host are routed the same way (router
state)– Example: ATM, Frame Relay, X.25