Transcript lecture 4
CSE 561 – Internetworking David Wetherall [email protected] Spring 2000 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.2 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.3 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.4 Fragmentation Issue • Different networks may have different frame limits (MTUs) H2 H1 H3 – Ethernet 1.5K, FDDI 4.5K Network 2 (Ethernet) • 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 djw // CS 561, Spring 2000 R1 Fragment? H4 Network 3 (FDDI) H5 H6 L4.5 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) djw // CS 561, Spring 2000 0 4 Version 8 HLen 16 TOS 31 Length Identifier for Fragments TTL 19 Flags Protocol Fragment Offset Checksum Source Address Destination Address Options (variable) Pad (variable) Data L4.6 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.7 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.8 IPv4 Address Formats Class A Class B Class C 0 1 1 7 24 Network Host 0 1 0 14 16 Network Host 21 8 Network Host • 32 bits written in “dotted quad” notation, e.g., 18.31.0.135 djw // CS 561, Spring 2000 L4.9 IPv6 Address Format 001 RegistryID ProviderID SubscriberID SubnetID InterfaceID • 128 bits written in 16 bit hexadecimal chunks • Still hierarchical, just more levels djw // CS 561, Spring 2000 L4.10 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.11 ICMP Generation Error during forwarding! IP packet source dest ICMP IP packet djw // CS 561, Spring 2000 L4.12 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.13 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.14 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.15 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.16 TCP Header Format • Sequence and Ack numbers used for the sliding window – Congestion control works by controlling the window size 0 10 4 16 31 SrcPort DstPort SequenceNum Acknow ledgment HdrLen 0 Flags AdvertisedWindow Checksum UrgPtr Options (variable) Data djw // CS 561, Spring 2000 L4.17 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.18 Three-Way Handshake • Opens both directions for transfer Active participant (client) Passive participant (server) +data djw // CS 561, Spring 2000 L4.19 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.20 Again, with States Active participant (client) Passive participant (server) SYN_SENT LISTEN SYN_RCVD ESTABLISHED ESTABLISHED +data djw // CS 561, Spring 2000 L4.21 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.22 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.23 TCP Connection Teardown • Symmetric close – both sides shutdown independently Web server Web browser FIN_WAIT_1 CLOSE_WAIT LAST_ACK FIN_WAIT_2 TIME_WAIT … CLOSED djw // CS 561, Spring 2000 CLOSED L4.24 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.25 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.26 Sender and Receiver Buffering Sending application Receiving application TCP TCP LastByteWritten LastByteAcked LastByteSent = available buffer djw // CS 561, Spring 2000 LastByteRead NextByteExpected LastByteRcvd = buffer in use L4.27 Example – Exchange of Packets T=1 T=2 T=3 Stall due to T=4 flow control T=5 here Receiver has buffer of size 4 and application doesn’t read T=6 djw // CS 561, Spring 2000 L4.28 Example – Buffer at Sender T=1 1 2 3 4 5 6 7 8 9 T=2 1 2 3 4 5 6 7 8 9 =acked =sent T=3 1 2 3 4 5 6 7 8 9 T=4 1 2 3 4 5 6 7 8 9 T=5 1 2 3 4 5 6 7 8 9 T=6 1 2 3 4 5 6 7 8 9 djw // CS 561, Spring 2000 =advertised L4.29 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.30 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.31 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.32 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 djw // CS 561, Spring 2000 L4.33