Transports and TCP Transports and TCP Adolfo Rodriguez CPS 214 - PowerPoint PPT Presentation

Transports and TCP Transports and TCP Adolfo Rodriguez CPS 214

Host- -to to- -Host vs. Host vs. Host Process- -to to- -Process Communication Process Communication Process � Until now, we have focused on delivering packets between arbitrary hosts connected to Internet • Routing protocols • IP best effort delivery model • Scalability and robustness through hierarchy and soft state � Transition to arbitrary processes communicating together • One goal: provide illusion that all processes located on one large computer • Can address ( name) and reliably communicate with any process Ports

UDP UDP � User Datagram Protocol (UDP) • Simple demultiplexing No guarantees about reliability, in-order delivery • Thin veneer on top of IP adds src/dest port numbers 16 bit port number allows for identification of 65536 unique communication endpoints per host Note that a single process can utilize multiple ports IP addr + port number uniquely identifies all Internet endpoints • UDP Packet Link-layer IP SrcPort DestPort Checksum Len Data… UDP Header

A Brief Internet History A Brief Internet History 1991 WWW/HTTP 1990 1972 ARPANET 1995 TELNET dissolved RFC 318 Multi-backbone 1986 Internet NNTP 1992 1969 1984 1973 1977 1982 RFC 977 MBONE ARPANET DNS FTP MAIL TCP & IP created RFC 883 RFC 454 RFC 733 RFC 793 & 791 1970 1980 1985 1990 1995 1975

TCP Timeline TCP Timeline 1984 1987 1975 Nagel’s algorithm 1990 to reduce overhead Karn’s Three-way handshake of small packets; 4.3BSD Reno algorithm Raymond Tomlinson fast retransmit predicts congestion to better estimate In SIGCOMM 75 delayed ACK’s collapse round-trip time 1983 1986 1988 BSD Unix 4.2 1974 Van Jacobson’s Congestion supports TCP/IP TCP described by algorithms collapse Vint Cerf and Bob Kahn congestion avoidance observed 1982 In IEEE Trans Comm and congestion TCP & IP control RFC 793 & 791 ( most implemented in 4.3BSD Tahoe ) 1980 1990 1985 1975

TCP: After 1990 TCP: After 1990 1994 1996 T/TCP SACK TCP Interaction of real-time (Braden) (Floyd et al) protocols with TCP? Transaction Selective XCP… TCP Acknowledgement 1996 1996 1993 1994 FACK TCP Hoe TCP Vegas ECN (Mathis et al) Improving TCP (Brakmo et al) (Floyd) extension to SACK startup real congestion Explicit Congestion avoidance Notification 1999 1993 1994 1996

TCP TCP � Transmission Control Protocol (TCP) • Reliable in-order delivery of byte stream • Full duplex (endpoints simultaneously send/receive) e.g., single socket for web browser talking to web server • Flow-control To ensure that sender does not overrun receiver Fast server talking to slow client • Congestion control Keep the sender from overrunning the network Many simultaneous connections across routers (cross traffic)

TCP TCP � Utilize sliding window protocol, plus: • Need for connection establishment (no dedicated cable) • Varying round trip times over life of connection Different paths, different levels of congestion • Ready for very old packets • Delay-bandwidth product highly variable Amount of available buffer space at receivers also variable • Sender has no idea what links will be traversed to receiver Must dynamically estimate changing end-to-end characteristics

TCP Flavors TCP Flavors � TCP Tahoe • Jacobson’s implementation of congestion control (AIMD) � TCP Reno • Fast recovery • Fast retransmit • Delayed ACK’s � TCP Vegas • Source-based congestion avoidance rather than control • TCP Reno needs to cause congestion to determine available bandwidth

TCP Header Format TCP Header Format 0 4 10 16 31 SrcPort DestPort SequenceNum Acknowledgment HdrLen 0 Flags AdvertisedWindow CheckSum UrgPtr Options (variable) Data � Without options, TCP header 20 bytes • Thus, typical Internet packet minimum of 40 bytes

TCP Connection Establishment TCP Connection Establishment � Exchange necessary information to begin communication � Three-way handshake • E.g., server listening on socket Client Server S Y N , s e q u e n c e # = x y = # e c n e u q e S , K 1 C + A x + = t N n e Y m S g d e l w o n k c A A C K , A c k n o w l e d g e m e n t = y + 1

TCP Connection Teardown TCP Connection Teardown � Closing process sends a FIN message • Waits for ACK of FIN to come back • This side of the connection is now closed � Each side of a TCP connection can independently close the connection • Thus, possible to have a half duplex connection

Reliable Transmission Reliable Transmission � How do we send a packet reliably when it can be lost? � Two mechanisms • Acknowledgements • Timeouts � Simplest reliable protocol: Stop and Wait

Stop and Wait Stop and Wait Send a packet, stop and wait until acknowledgement arrives Sender Receiver P a c k e t Timeout Time ACK

Recovering From Error Recovering From Error P P P a a a c c c k k k e e e t t t Timeout Timeout Timeout ACK ACK Time P a c k e t P P a a c c k k e e t t Timeout Timeout Timeout ACK ACK ACK ACK lost Packet lost Early timeout

Problems with Stop and Wait Problems with Stop and Wait � How to recognize a duplicate transmission? • Solution: put sequence number in packet � Performance • Unless Latency-Bandwidth product is very small, sender cannot fill the pipe • Solution: sliding window protocols

Keeping the Pipe Full Keeping the Pipe Full Bandwidth Latency � Bandwidth-Delay product measures network capacity � How much data can you put into the network before the first byte reaches receiver � Stop and Wait: 1 data packet per RTT • Ex. 1.5-Mbps link with 45-ms RTT • Stop-and-wait: 182 Kbps � Ideally, send enough packets to fill the pipe before requiring first ACK

How Do We Keep the Pipe Full? How Do We Keep the Pipe Full? � Send multiple packets without waiting for first to be ACK’d � Reliable, unordered delivery: • Send new packet after each ACK • Sender keeps list of unack’d packets; resends after timeout � Ideally, first ACK arrives immediately after pipe is filled • Opens up another “slot”

TCP Flow Control TCP Flow Control � TCP is a sliding window protocol • For window size n , can send up to n bytes without receiving an acknowledgement • When the data is acknowledged then the window slides forward � Each packet advertises a window size in TCP header • Indicates number of bytes the receiver is willing to get � Original TCP always sent entire window immediately • Too bursty?

Sliding Window Sliding Window � Receivers buffer later packets until prior packets arrive • For out of order delivery � Sender must prevent buffer overflow at receiver • Flow control � Solution: sliding window • Circular buffer at sender and receiver Packets in transit <= buffer size Advance when sender and receiver agree packets at beginning have been received

Visualizing the Window Visualizing the Window offered window (advertised by receiver) usable window 1 2 3 4 5 6 7 8 9 10 11 12 sent and can send ASAP can’t send until acknowledged sent, not ACKed window moves Left side of window advances when data is acknowledged. Right side controlled by size of window advertisement.

Visualizing the Window: Example Visualizing the Window: Example Initial State, Receiver has 6 slots to buffer packets Packets 4, 5, 6 sent, but not yet received advertised window 1 2 3 4 5 6 7 8 9 10 11 12 Sender sent and can send ASAP can’t send until acknowledged sent, not ACKed window moves offered window 1 2 3 4 5 6 7 8 9 10 11 12 Receiver ACK’d and Available bufs can’t recv until read window moves

Visualizing the Window: Example Visualizing the Window: Example Receiver to Sender � ACK 5, Window 4 advertised window 1 2 3 4 5 6 7 8 9 10 11 12 Sender sent and can send ASAP can’t send until acknowledged sent, not ACKed window moves offered window 1 2 3 4 5 6 7 8 9 10 11 12 Receiver ACK’d and Available bufs can’t recv until read ACK’d, not read window moves

Visualizing the Window: Example Visualizing the Window: Example Sender to Receiver � Send 7, 8, 9 advertised window 1 2 3 4 5 6 7 8 9 10 11 12 Sender sent and can’t send until acknowledged sent, not ACKed window moves offered window 1 2 3 4 5 6 7 8 9 10 11 12 Receiver ACK’d and Available bufs can’t recv until read ACK’d, not read window moves

Visualizing the Window: Example Visualizing the Window: Example Receiver to Sender � ACK 9, Window 0 advertised window=0 1 2 3 4 5 6 7 8 9 10 11 12 Sender sent and can’t send until acknowledged window moves offered window=0 1 2 3 4 5 6 7 8 9 10 11 12 Receiver ACK’d and can’t recv until read window moves ACK’d, not read

Visualizing the Window: Example Visualizing the Window: Example Receiver App reads packets 4, 5, 6 But sender has no way of knowing that more room is available! advertised window=0 1 2 3 4 5 6 7 8 9 10 11 12 Sender sent and can’t send until acknowledged window moves offered window=3 1 2 3 4 5 6 7 8 9 10 11 12 Receiver ACK’d and read ACK’d, not read Available bufs