TCP/IP Revisited Computer Science 742 S2C, 2014

Transcription

1 TCP/IP, COMPSCI 742, 2014 p. 1/33 TCP/IP Revisited Computer Science 742 S2C, 2014 Nevil Brownlee, with acknowledgements to Ulrich Speidel

2 UDP TCP/IP, COMPSCI 742, 2014 p. 2/33 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

3 TCP [p 378 / 384] TCP/IP, COMPSCI 742, 2014 p. 3/33 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

4 TCP port assignment TCP/IP, COMPSCI 742, 2014 p. 4/33 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 or System port. It will use a random high-numbered port as its SrcPort Many applications these days use port numbers Port numbers up to may be allocated by IANA as User ports. Port numbers above that are ephemeral, i.e. allocated by the IP stack in response to an incoming connection 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

5 TCP Sequence number TCP/IP, COMPSCI 742, 2014 p. 5/33 A TCP connection may carry thousands of datagrams (TCP segments) 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 Start at a random value. TCP implementations do this so as to make it harder for attackers to guess their initial value Can also be used as SYN cookies, allowing a TCP server to time out an attacker s half-open connections Wrap-around: sequence number is followed by sequence number 0 (assuming one-byte datagrams) TCP sequence numbers use unsigned 32-bit arithmetic

6 TCP acknowledgements TCP/IP, COMPSCI 742, 2014 p. 6/33 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 ACK 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?

7 TCP header length TCP/IP, COMPSCI 742, 2014 p. 7/33 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 bytes Everything following the header is payload (data that is to be delivered to the application)

8 TCP flags (1) TCP/IP, COMPSCI 742, 2014 p. 8/33 Eight 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 ACK: 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 ACK flags are enough to get a connection established

9 TCP flags (2) TCP/IP, COMPSCI 742, 2014 p. 9/33 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. Intended for use in case of errors should not see this normally, but some applications use it to close a TCP connection in a hurry Other flags: PUSH: Indicates receiver should pass all data in its buffer to application. Not very useful these days URG: Poorly defined, seldom (if ever) used ECE, CWR: Are part of ECN (Explicit Congestion Notification) CWR: Congestion Window Reduced ECE: ECN-Echo (sender should reduce send window size)

10 TCP connection handshake (simplest case) TCP/IP, COMPSCI 742, 2014 p. 10/33 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+ACK set, Ack field contains 383, Sequence field is, say, Host A sends datagram that has ACK set, Ack field contains Client now regards the connection as established, sequence number is still 383 Note that: the SYN flag counts as one byte host A s second datagram completes the connection handshake. It could also carry data, e.g. an HTTP GET request any of these opening packets can be lost, in which case they will be re-sent

11 TCP acknowledgement TCP/IP, COMPSCI 742, 2014 p. 11/33 One side (host A) sends one-byte datagram with sequence number, say 387 Other side (host B) responds with datagram that has ACK set. Acknowledgement field contains number 388, its own sequence number is, say, Host A now knows that host B has received all bytes from host A up to and including number 387 note: ACK 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 ACK from B contains an earlier sequence number After an appropriate timeout, A resends the missing datagram(s) Problem: What is an appropriate waiting time?

12 TCP flow control: sliding window TCP/IP, COMPSCI 742, 2014 p. 12/33 Receiver advertises a window in its datagrams that have the ACK 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

13 Adaptive retransmission (1) TCP/IP, COMPSCI 742, 2014 p. 13/33 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

14 Adaptive retransmission (2) TCP/IP, COMPSCI 742, 2014 p. 14/33 Time each frame: measure time between transmission of the datagram and arrival of its corresponding ACK. 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: ACKs 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

15 TCP state diagram (RFC 793) TCP/IP, COMPSCI 742, 2014 p. 15/33 Active Open SYN CLOSE FIN CLOSE SYN_SENT CLOSE_WAIT LAST_ACK CLOSED ACK (of FIN) ACK ACK Active SEND SYN SYN+ACK ACK FIN ACK Send remaining data in buffer TIMEOUT (2x MSL) CLOSED CLOSE LISTEN ESTABLISHED CLOSING ACK (of FIN) TIME_WAIT Passive Open ACK ACK Legend: SYN SYN+ACK SYN ACK Normal operation ACK (of SYN) CLOSE FIN FIN+ACK ACK Receive remaining data from other side's buffer ACK ACK FIN ACK COMMAND from application FLAG received FLAG sent SYN_RECV CLOSE FIN FINWAIT_1 ACK (of FIN) FINWAIT_2

16 TCP Congestion Management [p 468 / 474] TCP/IP, COMPSCI 742, 2014 p. 16/33 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

17 TCP Congestion Management (2) TCP/IP, COMPSCI 742, 2014 p. 17/33 Additive increase / multiplicative decrease (AI/MD) increment cwin once per RTT until a segment is lost halve cwin and repeat Note that (endogenous) packet loss is forced as part of TCP s congestion management; it s quite different to exogenous losses due to transmission errors, e.g. those caused by interference on wireless links RFC 2309 Recommendations on Queue Management and Congestion Avoidance in the Internet

18 TCP errors, etc. TCP/IP, COMPSCI 742, 2014 p. 18/33 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

19 Algorithms used in TCP Implementation TCP/IP, COMPSCI 742, 2014 p. 19/33 When to send data Nagle: if (< mss bytes && 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..3 segments), increment by mss each ACK up to ssthresh (init 65535) Congestion Avoidance: AI/MD Fast Retransmit: resend after third duplicate ACK Fast Recovery: don t Slow Start after Fast Retransmit

20 Congestive collapse TCP/IP, COMPSCI 742, 2014 p. 20/33 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

21 Synchronisation of TCP connections TCP/IP, COMPSCI 742, 2014 p. 21/33 Traffic on an Ethernet segment is self-similar, i.e. it s bursty, at all time scales Thats less true for low-volume Internet traffic, but becomes more apparent for volumes above about 40 Mb/s Several papers have suggested that s because concurrent TCP connections often share (parts of) the same path if that path is congested, any or all of the TCP connections may drop a packet at full buffer queues The effect is that concurrent TCP connections tend to synchronise, especially if their paths have the same RTT

22 Flavours of TCP (1) TCP/IP, COMPSCI 742, 2014 p. 22/33 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 ACK 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 ACK for resent segment, switch to slow start delayed ACKs: only send an ACK for every second packet the most widely-deployed TCP implementation

23 Flavours of TCP (2) TCP/IP, COMPSCI 742, 2014 p. 23/33 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 Long Fat pipes consider a 1 Gb/s path with 200 ms round-trip time (RTT) assuming ~1 kb TCP segments, we can get about 200 of them on the wire in additive increase mode, it would take about 20 s before TCP s congestion window fills the path

24 Flavours of TCP (3) TCP/IP, COMPSCI 742, 2014 p. 24/33 BIC: 2004 Binary Increase Congestion Control for Fast Long-Distance Networks, Xu, Harfoush and Rhee, March 2004 BIC grows its congestion window faster than linearly, while trying to be fair to other TCP connections CUBIC: 2008 CUBIC: a new TCP-friendly high-speed TCP variant, Ha, Rhee and Xu, March 2008 cubic function for congestion window growth fairer than BIC to other TCP connections implemented in Linux kernel Note: new implementations of TCP must interwork properly with existing ones! both BIC and CUBIC have a minimum window size, below that they use classic TCP behaviour

25 Further reading TCP/IP, COMPSCI 742, 2014 p. 25/33 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 SACK TCP, Kevin Fall, Sally Floyd, CACM, vol 26, pp5-21, All these are on the 742 Resources web page

26 TCP Steady State Throughput Formula TCP/IP, COMPSCI 742, 2014 p. 26/33 Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, Teunis Ott, The Macroscopic Behaviour of the TCP Congestion Avoidance Algorithm, SIGCOMM, July 1997

27 TCP Throughput Formula (2) TCP/IP, COMPSCI 742, 2014 p. 27/33 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 RTT 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 RTT

28 A different model of TCP TCP/IP, COMPSCI 742, 2014 p. 28/33 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 Downey s model begins in slow start, and has three other states: congestion avoidance buffer limited self clocking We ll look at a few slides from one of Allen s talks...

29 Downey s model (1) TCP/IP, COMPSCI 742, 2014 p. 29/33

30 Downey s model (2) TCP/IP, COMPSCI 742, 2014 p. 30/33

31 Downey s model (3) TCP/IP, COMPSCI 742, 2014 p. 31/33

32 Downey s model, summary TCP/IP, COMPSCI 742, 2014 p. 32/33 Based on observation of data transfers Observations were used to build distributions of TCP window sizes Three steady-state behaviours Self-clocking seemed to be fairly common

33 Measuring bulk transfer capacity (BTC) TCP/IP, COMPSCI 742, 2014 p. 33/33 Many web pages offering download speed tests they usually do this by downloading a big file to your host, and measuring the time that download takes Unfortunately, a running TCP transfer establishes a dynamic equilibrium! Remember the MSMO equation? BW = MSS C RTT p RTT is fixed for a connection MSS may vary, assume it s 1460 also assume that the exogenous drop rate p is negligible TCP will generate endogenous drops so as to set p that will determine the observed BW In short, the measurement perturbs the system we can t make a reliable, accurate measurement this way! See Why is BTC so hard? at