Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSE 561 – Internetworking David Wetherall Spring 2000.

Similar presentations


Presentation on theme: "CSE 561 – Internetworking David Wetherall Spring 2000."— Presentation transcript:

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

2 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

3 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

4 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

5 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 H3 H2 H1 Network 2 (Ethernet) H6 Network 3 (FDDI) Fragment?

6 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) VersionHLen TOSLength Identifier for FragmentsFlagsFragment Offset TTLProtocolChecksum Source Address Destination Address Options (variable) Pad (variable) 048161931 Data

7 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

8 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

9 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.31.0.135 Class A Class B Class C

10 djw // CS 561, Spring 2000 L4.10 IPv6 Address Format 128 bits written in 16 bit hexadecimal chunks Still hierarchical, just more levels SubscriberIDProviderIDRegistryID001InterfaceIDSubnetID

11 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

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

13 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

14 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.

15 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)

16 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

17 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

18 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

19 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

20 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

21 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

22 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 …

23 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!

24 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 …

25 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

26 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

27 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

28 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 doesn’t read Stall due to flow control here T=1 T=2 T=3 T=4 T=5 T=6

29 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

30 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

31 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

32 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

33 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


Download ppt "CSE 561 – Internetworking David Wetherall Spring 2000."

Similar presentations


Ads by Google