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 Dont 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 H3 H2 H1 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) Dont Fragment (DF) VersionHLen TOSLength Identifier for FragmentsFlagsFragment Offset TTLProtocolChecksum Source Address Destination Address Options (variable) Pad (variable) 048161931 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 dont 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 NetworkHost 724 0 NetworkHost 1416 10 NetworkHost 218 110 IPv4 Address Formats 32 bits written in dotted quad notation, e.g., 18.104.22.168 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 SubscriberIDProviderIDRegistryID001InterfaceIDSubnetID
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 Error during forwarding!
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! Dont 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 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
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 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 serverWeb browser FIN ACK FIN FIN_WAIT_1 CLOSE_WAIT LAST_ACK FIN_WAIT_2 TIME_WAIT CLOSED
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 LastByteSent LastByteAcked 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=3 SEQ=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 doesnt read Stall 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 213456789 213456789 213456789 213456789 213456789 213456789 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