1 / 33

CSE 561 – Internetworking

CSE 561 – Internetworking. David Wetherall djw@cs.washington.edu 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.

yahto
Download Presentation

CSE 561 – Internetworking

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSE 561 – Internetworking David Wetherall djw@cs.washington.edu Spring 2000

  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

  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

  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

  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 H2 H1 H3 Network 2 (Ethernet) Fragment? R1 H4 Network 3 (FDDI) H5 H6 djw // CS 561, Spring 2000

  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) 0 4 8 16 19 31 TOS Length V ersion HLen Identifier for Fragments Flags Fragment Offset TTL Protocol Checksum Source Address Destination Address Pad Options (variable) (variable) Data djw // CS 561, Spring 2000

  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

  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

  9. IPv4 Address Formats 7 24 • 32 bits written in “dotted quad” notation, e.g., 18.31.0.135 Class A 0 Network Host 14 16 Class B 1 0 Network Host 21 8 Class C 1 1 0 Network Host djw // CS 561, Spring 2000

  10. IPv6 Address Format • 128 bits written in 16 bit hexadecimal chunks • Still hierarchical, just more levels 001 RegistryID ProviderID SubscriberID SubnetID InterfaceID djw // CS 561, Spring 2000

  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

  12. ICMP Generation Error during forwarding! IP packet source dest ICMP IP packet djw // CS 561, Spring 2000

  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

  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

  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

  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

  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

  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

  19. Three-Way Handshake • Opens both directions for transfer Active participant Passive participant (client) (server) SYN, SequenceNum = x , y 1 + SYN + ACK, SequenceNum = x Acknowledgment = ACK, Acknowledgment = y + 1 +data djw // CS 561, Spring 2000

  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

  21. Again, with States Active participant Passive participant (client) (server) SYN_SENT LISTEN SYN, SequenceNum = x SYN_RCVD , y 1 + SYN + ACK, SequenceNum = x Acknowledgment = ESTABLISHED ACK, Acknowledgment = ESTABLISHED y + 1 +data djw // CS 561, Spring 2000

  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

  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

  24. TCP Connection Teardown • Symmetric close – both sides shutdown independently Web server Web browser FIN_WAIT_1 FIN CLOSE_WAIT ACK LAST_ACK FIN FIN_WAIT_2 TIME_WAIT ACK … CLOSED CLOSED djw // CS 561, Spring 2000

  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

  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

  27. Sender and Receiver Buffering Receiving application Sending application TCP TCP LastByteRead LastByteWritten LastByteSent LastByteAcked NextByteExpected LastByteRcvd = available buffer = buffer in use djw // CS 561, Spring 2000

  28. Example – Exchange of Packets SEQ=1 T=1 ACK=2; WIN=3 T=2 SEQ=2 Receiver has buffer of size 4 and application doesn’t read ACK=3; WIN=2 T=3 SEQ=3 Stall due to flow control here T=4 SEQ=4 ACK=4; WIN=1 T=5 ACK=5; WIN=0 T=6 djw // CS 561, Spring 2000

  29. Example – Buffer at Sender T=1 1 2 3 4 5 6 7 8 9 =acked T=2 1 2 3 4 5 6 7 8 9 =sent T=3 1 2 3 4 5 6 7 8 9 =advertised 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

  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

  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

  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

  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 djw // CS 561, Spring 2000

More Related