TCP/IP, COMPSCI 742, 2010 p. 3/29 IP s Transport Layer UDP and TCP TCP/IP, COMPSCI 742, 2010 p. 4/29 TCP/IP Revisited Computer Science 742 S2C, 2010 Nevil Brownlee, with acknowledgements to Ulrich Speidel You should be familiar with IP from 314 or equivalent experience Buzzwords to look up: IP addresses, IP routing, best effort, fragmentation, time-to-live TCP or UDP comes in packets (frames, datagrams) that are encapsulated as payload inside an IP datagram There are many other Transport Protocols, e.g. DCCP provides various types of congestion management over IP, for applications that don t need reliability SCTP carries sequenced streams of datagrams RTP carries multimedia streams UDP TCP/IP, COMPSCI 742, 2010 p. 1/29 TCP TCP/IP, COMPSCI 742, 2010 p. 2/29 UDP is used to send individual datagrams from an application on one computer to another application on a different computer across the network Applications are identified by 16-bit port numbers on either side Delivery is best effort, not guaranteed Applications that require recovery from lost transmissions must implement their own detection and recovery protocol TCP: Transmission Control Protocol, RFC 793 Provides a reliable bi-directional byte stream channel between an application on one computer and another application on a different computer across the network Applications identified by 16-bit port numbers at each end Delivery is guaranteed, i.e. TCP handles error detection and recovery TCP is usually described as connection oriented sender and receiver establish initial state they maintain that state during the connection lifetime state is forgotten when the connection ends contrast that with virtual circuit networking, where connection state is stored in switches throughout the network
TCP datagram format TCP/IP, COMPSCI 742, 2010 p. 7/29 TCP port assignment TCP/IP, COMPSCI 742, 2010 p. 8/29 0 4 10 16 31 Source Port Dest Port U A P R S F Hdr Len 000000 R C S S Y IN Advertised Window G K H T N TCP Checksum Sequence Number Acknowledgement Number Urgent Pointer Options (variable length) Port numbers are the first two 16-bit fields in the TCP header TCP is a symmetric protocol, both ends can send and receive streams of data bytes A client machine connecting to a server will usually attempt to open a TCP connecton to a well-known port. It will use a random high-numbered port as its SrcPort. Many applications these days use port numbers 1024 Note that SrcPort and DestPort do not depend on who is client and who is server, but on the direction in which the datagram travels TCP payload (variable length) TCP Sequence number TCP/IP, COMPSCI 742, 2010 p. 5/29 TCP acknowledgements TCP/IP, COMPSCI 742, 2010 p. 6/29 A TCP connection may carry thousands of datagrams in each direction Must have a way to ensure they arrive in sequence and that we can detect missing ones SeqNum header field carries 32 bit sequence number of first byte in datagram. Sequence numbers apply to their datagram s respective direction Are supposed to start at a random value but may just start at 0; i.e. they may not be particularly random Can also be used as SYN cookies, allowing a TCP server to time out an attacker s half-open connections Wrap-around: sequence number 2 32 1 is followed by sequence number 0 (assuming one-byte datagrams) TCP sequence numbers use unsigned 32-bit arithmetic The Acknowledgement field contains the sequence number of the next byte that the machine expects to receive The sending machine can use it to determine how many of its transmitted datagrams have been successfully received Field is only valid if flag in flags field is set Timing issues (see later)! Ack packets can carry data bytes, but they usually do not. Many protocols carry most of their data in one direction; can you think of some which carry data in both directions?
TCP header length TCP/IP, COMPSCI 742, 2010 p. 11/29 TCP flags (1) TCP/IP, COMPSCI 742, 2010 p. 12/29 TCP header is not fixed in length can get different size headers depending on use of Options field HdrLen field gives the total size of the TCP header in four-byte units, i.e. length = HdrLen 4 Everything following the header is payload (data that is to be delivered to the application) Six bits in the TCP header are used for flags: SYN: Set when the client sends its first datagram to the server, and in the server s acknowledgement of that datagram. Basically, it marks the connection request/confirmation : Indicates that the Acknowledgement field contains a valid segment number. Remember that we can t set no value in a 32 bit field! SYN and flags are enough to get a connection established TCP flags (2) TCP/IP, COMPSCI 742, 2010 p. 9/29 TCP connection handshake (simplest case) TCP/IP, COMPSCI 742, 2010 p. 10/29 Flags which terminate a connection: FIN: Signals that a host has finished with a connection. The other host should finish too RESET: Shuts down the connection immediately. Used in case of errors should not see this in proper implementations! Other flags: PUSH: Indicates receiver should pass all data in its buffer to application. Not very useful these days URG: Indicates that UrgPtr points to last byte of urgent data, but there s no way to indicate the first byte of such data not often used Host A sends datagram with SYN flag set and an initial sequence number, say 382 in its Sequence field Host B responds with datagram that has SYN+ set, Ack field contains 383, Sequence field is, say, 12765 Host A sends datagram that has set, Ack field contains 12766. Client now regards the connection as established, sequence number is 383 Note that: The SYN flag counts as one byte Host A s second datagram completes the connection handshake. It can also carry data, e.g. an HTTP GET request
TCP acknowledgement TCP/IP, COMPSCI 742, 2010 p. 15/29 TCP flow control: sliding window TCP/IP, COMPSCI 742, 2010 p. 16/29 One side (host A) sends one-byte datagram with sequence number, say 387 Other side (host B) responds with datagram that has set. Acknowledgement field contains number 388, its own sequence number is, say, 12779 Host A now knows that host B has received all bytes from host A up to and including number 387 note: carries the sequence number of the next byte B expects to recieive If a datagram is lost on the way from A to B, next from B contains an earlier sequence number After an appropriate timeout, A resends the missing datagram(s) Problem: What is an appropriate waiting time? Receiver advertises a window in its datagrams that have the flag set: the number of bytes left in its receive buffer for the connection this is the number of bytes it can still receive Sender must ensure that there is at most this amount of unacknowledged data on the connection Problem: If receiver advertises window size 0, the sender will not know when the window size increases again Solution: sender sends small (ack) frame every so often; that evokes a response from receiver advertising the current window size Adaptive retransmission (1) TCP/IP, COMPSCI 742, 2010 p. 13/29 Adaptive retransmission (2) TCP/IP, COMPSCI 742, 2010 p. 14/29 Problem: datagrams in transit between sender and receiver are not included in the advertised window. By the time the advertised window size arrives at the sender, it is out of date How big is the problem? Depends on bandwidth-delay product. On a connection between NZ and the US that terminates in 100 Mb/s Ethernet either side and has 100 ms latency, it s no less than 10 Mb, i.e., about 1 MB of payload data! A big problem indeed, especially for people in NZ! Need some sort of algorithm that can handle this data in transit Time each frame: measure time between transmission of the datagram and arrival of its corresponding. Use that as estimate of round-trip time (RTT) Sending side computes capacity of receiver buffers plus channel and can (conservatively) transmit data until this capacity is reached Problem: s are not associated with a particular copy of a datagram is it for the original or the resend? Can t compute RTT values for such cases Karn/Partridge: double RTT timeout every time a datagram needs to be resent ( exponential backoff ). Only do calculation for packets that are not resent Karels/Jacobson: compute RTT timeout more closely based on RTT statistics
TCP in more detail [p 378 / 384] TCP/IP, COMPSCI 742, 2010 p. 19/29 TCP state diagram (RFC 793) TCP/IP, COMPSCI 742, 2010 p. 20/29 Ordered delivery Each end has a buffer for the max window size Max receive window sent in each segment Sequence number = nbr of first byte Acknowledgement number = nbr of next expected byte Seq + TCP length = Ack (when Acking a single segment) Out-of-sequence segments re-send earlier Ack Sequence numbers are 32-bit unsigned, and will wrap Flow control Don t send more data than will fit in the receive window Receive window size changes as data removed from buffer Active Open SYN CLOSED Legend: CLOSE Active SEND SYN CLOSE Passive Open COMMAND from application FLAG received FLAG sent SYN_SENT LISTEN SYN SYN+ SYN SYN+ SYN_RECV (of SYN) FIN Normal operation CLOSEFIN CLOSEFIN CLOSE_WAIT LAST_ CLOSED Send remaining data in buffer ESTABLISHED CLOSE FIN FINWAIT_1 CLOSING FIN+ (of FIN) (of FIN) (of FIN) Receive remaining data from other side s buffer TIMEOUT (2x MSL) FINWAIT_2 TIME_WAIT FIN TCP Congestion Management [p 468 / 474] TCP/IP, COMPSCI 742, 2010 p. 17/29 TCP Congestion Management (2) TCP/IP, COMPSCI 742, 2010 p. 18/29 Feedback scheme Idea is to use Acks to clock packets onto link RFC 2581 Sender maintains congestion window, never sends more than min(cwin, rwin) bytes Slow Start Begin by sending 1..3 packets Increment cwin each Ack segment until a segment is lost Halve cwin, switch to AI/MD Additive increase / multiplicative decrease (AI/MD) Increment cwin once per RTT until a segment is lost Halve cwin and repeat Note that packet loss is required for TCP congestion management RFC 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet
TCP errors, etc. TCP/IP, COMPSCI 742, 2010 p. 23/29 Algorithms used in TCP Implementation TCP/IP, COMPSCI 742, 2010 p. 24/29 Error handling Lost segment detected by timeout, or by receiving three duplicate Acks Fast retransmit: re-send segment starting with Ack byte (only re-send one segment) Half-open connections From host which crashed (without sending FINs) Keepalive packets Some implementations send these, and close connections if no data bytes are sent during the timeout interval This is not part of the TCP protocol, sessions stay open until they are closed by FIN or RST When to send data Nagle: if (< mss bytes and unacked bytes) wait else send Measuring RTT Karn/Partridge: don t time retransmitted segments Jacobson/Karels: allow for variance in RTTs Congestion Management Slow Start: set cwind = IW (usually 1 or 2 segments), increment by SMSS each up to ssthresh (init 65535) Congestion Avoidance: AI/MD Fast Retransmit: resend after third duplicate Fast Recovery: don t Slow Start after Fast Retransmit Congestive collapse TCP/IP, COMPSCI 742, 2010 p. 21/29 Flavours of TCP (1) TCP/IP, COMPSCI 742, 2010 p. 22/29 In case of congestion on data networks, there is a condition called congestive collapse Under TCP, when datagrams do not get through, TCP s RTT will back off exponentially can reach total inactivity pretty quickly! Back-off is designed to relieve pressure on resources Only works fairly if everyone keeps to the rules (no DoS attacks). Even so, retries create extra traffic Congestive collapse occurs when almost the entire traffic consists of retransmissions that don t get through as a result of the congestion, in turn generating retries No back-off in other protocols, e.g. UDP P&D [494] say that TCP is defined by an implementation We look (briefly) at the best-known implementations: Tahoe: the original BSD implementation of TCP (BNR1) begins in slow start, reaches ssthresh then switches to congestion avoidance detects loss by timeout before getting an set cwin to one and switch back to slow start Reno: added more algorithms to improve data transfer rate fast retransmit: three duplicate acks indicate packet loss; resend the missing segment, halve cwin, switch to fast recovery fast recovery: if no for resent segment, switch to slow start delayed s: only send an for every second packet the most widely-deployed TCP implementation
Flavours of TCP (2) TCP/IP, COMPSCI 742, 2010 p. 27/29 Further reading TCP/IP, COMPSCI 742, 2010 p. 28/29 Vegas: mid-90 s[495] observe data rate using RTTs for recent packets, detect changes in rate adjust cwin up or down, attempting to match the observed rate to the expected rate idea is to keep enough bits on the wire, without getting lots of bits (packets) backed up in router buffers, i.e. use queueing delay instead of loss probability to detect congestion not widely deployed FAST TCP: 2005 tries to maintain constant number of packets on the wire variable-sized adjustments to cwin proprietary (patented), i.e. not following a standard RFCs covering TCP implementation RFC 2581: TCP Congestion Control READ THIS ONE! It s quite short, it explains TCP s four intertwined algorithms (for congestion control) very clearly RFC 3390: Increasing TCP s Initial Window Congestion in the Internet RFC 2309: Recommendations on Queue Management and Congestion Avoidance Simulation-based comparisons of Tahoe, Reno and S TCP, Kevin Fall, Sally Floyd, CACM, vol 26, pp5-21, 1996. All these are on the 742 Resources web page Note: new implementations of TCP must interwork properly with existing ones! TCP Throughput Formula TCP/IP, COMPSCI 742, 2010 p. 25/29 TCP Throughput Formula (2) TCP/IP, COMPSCI 742, 2010 p. 26/29 Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, Teunis Ott, The Macroscopic Behaviour of the TCP Congestion Avoidance Algorithm, SIGCOMM, July 1997 Data delivered = area under sawtooth, i.e. 3/8 W 2 Each cycle delivers 1/p packets (p is the packet loss rate) data per cycle BW = time per cycle = MSS RT T C p, and C = p 3/2 Note that BW is inversely proportional to p i.e. need low loss rates to get high bandwidth This is a very simple model of TCP behaviour, many other papers about TCP behaviour have been published Some authors suggest that a TCP sender sends packets in flights, and use those flights to measure RT T
A different model of TCP In 2003, Allen Downey (Boston University) published a paper summarising his observations of TCP behaviour, and presented a Markov Model based on them Allen s work was published as: (D96) An Empirical model of TCP transfers, Allen B. Downey, Olin College Technical Report, January 14, 2003 That paper is on the 742 resources web page TCP/IP, COMPSCI 742, 2010 p. 29/29