Arhitecturi și Protocoale de Comunicații (APC) Protocoale de nivel Transport

Transcription

1 Arhitecturi și Protocoale de Comunicații (APC) Protocoale de nivel Transport

2 End-to-end data transport Web apps HTTP File transfer FTP Other apps SMTP, POP, IMAP Other apps SMTP, POP, IMAP File transfer FTP Web apps HTTP Transport layer Controls end-to-end transfer. IP philosophy: minimum functionality in the network (best effort service). Important role reserved for transport layer protocols. Host Router(s) TL TL PHY NL DL PHY Octavian Catrina 2 NL DL NL DL PHY Host NL DL PHY

3 Transport layer: main functions Addressing Identify data transport endpoints ("applications"). Transport address = Network address + Transport selector (port). Error control (end-to-end) Connectionless: Detect and discard damaged data units. Connection-oriented: Ensure data stream integrity. Detect and correct lost, damaged, reordered data units. Flow control (end-to-end) Connection-oriented: Adapt the transmitter's data rate to the receiver's data rate. Congestion control Connection-oriented: Limit the transmitter's data rate to avoid network congestion. Octavian Catrina 3

4 Review: TCP/IP protocol stack Web browser, ,... Applications Application protocols: HTTP, SMTP, FTP,... Other user applications User space Application Programming Interface (API) IGMP RARP ICMP ARP TCP IP UDP RIP Transport OSPF Network OS kernel LAN DL technology WAN DL technology Data Link Octavian Catrina 4

5 Addressing Applications TCP, UDP IP DL PHY IP address + TCP/UDP port IP address + Protocol id IP address Applications TCP, UDP IP DL PHY Which host? IP address. 32 bits (IPv4), in IP packet header. Which transport protocol? Protocol id. 8 bits (IPv4), in IP packet header. Which application process (and communication endpoint)? TCP/UDP port number. 16 bits, TCP/UDP header. Octavian Catrina 5

6 TCP/UDP ports and the Client-Server model Server Wait for service request Receive request Serve request Send result Distributed application Client Start Send request Receive result Stop Transport protocol Server Listens continuously for requests on a port known to clients. Reserved server ports: < 1024 (see RFC 1700). However, many servers use port numbers > Client A currently unused port ( 1024) is dynamically allocated for the duration of its life. Issues request to known server port. Octavian Catrina 6

7 Example: HTTP server and clients neptun.elc.ro hugo.int.fr zola.int.fr port: 3135 HTTP client TCP IP HTTP session TCP connection : 3135, : 80 IP datagrams HTTP server HTTP port: 80 TCP IP HTTP session TCP connection : 5768, : 80 IP datagrams port: 5768 HTTP client TCP IP Clients connect to the "well-known" HTTP server port 80. A server can handle concurrently connections with multiple clients. They can always be distinguished because of different client side addresses (different client IP addresses or port numbers). Octavian Catrina 7

8 UDP datagrams Pseudoheader IP header (20 bytes + opt.) UDP header (8 bytes) UDP data Source IP address Destination IP address 0 Protocol (17) UDP datagram length Source UDP port Destination UDP port Length Checksum Data Pseudo-header Part of IP header contents. Accompanies UDP datagram at the interface between UDP and IP. UDP checksum Covers UDP datagram and pseudo-header. Checksum computation is optional. Octavian Catrina 8

9 TCP packets ("segments") Pseudoheader IP header (20 octets + opt.) TCP header (20 octets +opt.) TCP data Acknowledgement number (cumulative) Hdr.len. - Control bits Window (size) Checksum Source IP address Destination IP address 0 Protocol TCP segment length Source TCP port Sequence number Options (if any) Destination TCP port Urgent pointer Data (if any) Control bits (flags): URG ACK PSH RST SYN FIN Checksum covers TCP header, data and pseudo-header. Options: Selective acknowledgments (SACK), Max. Segment Size (MSS), etc. Octavian Catrina 9

10 TCP header fields Source Port: 16 bits. The source port number. Destination Port: 16 bits. The destination port number. Sequence Number: 32 bits. The sequence number of the first data octet in this segment (except when SYN is present). If SYN is present the sequence number is the initial sequence number (ISN) and the first data octet is ISN+1. Acknowledgment Number: 32 bits. If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. Header Length (Data Offset): 4 bits. The number of 32 bit words in the TCP Header. This indicates where the data begins. The TCP header (even one including options) is an integral number of 32 bits long. Reserved: 6 bits. Reserved for future use. Must be zero. Control Bits: 6 bits (from left to right): URG: Urgent Pointer field significant. ACK: Acknowledgment field significant. PSH: Push Function. RST: Reset the connection. SYN: Synchronize sequence numbers. FIN: No more data from sender. Window (size): 16 bits. The number of data octets beginning with the one indicated in the acknowledgment field which the sender of this segment is willing to accept. Checksum: 16 bits. The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and payload. Octavian Catrina 10

11 Overview of TCP operation User A (initiator) Open-Active CLOSED SYN-SENT Open-Success TCP A TCP B User B SYN,... SYN+ACK,... CLOSED Open-Passive LISTEN SYN-RCVD ESTABLISHED ACK,... Open-Success Send(dt[100]) Close FIN-WAIT-1 FIN-WAIT-2 Terminate TIME-WAIT CLOSED..., dt[100] FIN,... ACK,... ACK,... ACK,... FIN,... ESTABLISHED Receive(dt[100]) Closing CLOSE-WAIT Close LAST-ACK CLOSED Terminate (listener) Octavian Catrina 11

12 TCP state machine SYN RECVD Open- Passive/ SYN/ SYN+ACK ACK/ RST/ CLOSED LISTEN Close/ Open- Active/SYN SYN+ACK/ACK SYN SENT U-1 TCP-1 TCP-2 U-2 CLOSED CLOSED Open-Active Open-Passive SYN-SENT [SYN,...] LISTEN Open-Success [SYN+ACK,...] SYN-RCVD ESTAB. [ACK,...] Open-Success Send(100) ESTAB. [..., data(100)] Close/FIN FIN WAIT-1 ACK/ FIN WAIT-2 Close/FIN FIN/ACK FIN-ACK/ACK FIN/ACK ESTAB- LISHED CLOSING ACK/ TIME WAIT FIN/ACK Exp. 2*MSL CLOSE WAIT Close/FIN LAST ACK ACK/ Close FIN-WAIT-1 FIN-WAIT-2 Terminate TIME-WAIT CLOSED [ACK,...] [FIN,...] [ACK,...] [FIN,...] [ACK,...] Deliver(100) Closing CLOSE-WAIT Close LAST-ACK Terminate CLOSED Octavian Catrina 12

13 TCP state machine (cont.) LISTEN - waiting for a connection request (CTRL=SYN) from any remote TCP. SYN-SENT - waiting for a matching reply after having sent a connection request (CTRL=SYN). SYN-RECEIVED - waiting for a matching connection acknowledgment (CTRL=ACK) after having received a connection request (CTRL=SYN) and replied (CTRL=SYN+ACK). ESTABLISHED - connection is open, user data can be sent and received. FIN-WAIT-1 - waiting for connection termination request from the remote TCP (CTRL=FIN+ACK), or acknowledgment of the termination request previously sent. FIN-WAIT-2 - waiting for a connection termination request from the remote TCP. CLOSE-WAIT - waiting for a connection termination request from the local user. CLOSING - waiting for connection termination request acknowledgment from remote TCP. LAST-ACK - waiting for acknowledgment of the connection termination request previously sent to the remote TCP (after acknowledging its termination request). TIME-WAIT - waiting for enough time to pass to be sure the remote TCP received the acknowledgment of its connection termination request. CLOSED - no connection active or pending. Octavian Catrina, International University in Germany 13

14 Connection establishment User A (initiator) Open-Active CLOSED SYN-SENT Open-Success ESTABLISHED TCP A TCP B User B (listener) SYN, seq=x, wnd=w1 ACK, seq=x+1, ack=y+1 SYN+ACK seq=y, ack=x+1, wnd=w2 CLOSED Open-Passive LISTEN SYN-RCVD Open-Success ESTABLISHED Passive open: Listener (e.g., server) is ready to communicate. Accepts incoming connections on specified port number. Active open: User initiates the communication (e.g., client). SYN segment: Requests the establishment of a new connection. SYN+ACK segment: Confirms (accepts) the connection establishment. Three-way handshake procedure Together with the choice of initial sequence numbers avoids connection establishment anomalies. Octavian Catrina 14

15 Example: Connection establishment TCP connection establishment from to with negotiation of TCP options TCP options in this example: Maximum data segment size = 1460 octets (MSS option). Selective acknowledgments (SACK option). SYN segment details Supports (and wants to use) the selective acknowledgement (SACK) mechanism Octavian Catrina 15

16 Data transfer Reliable transfer of byte streams Same octet values, same octet count and order. Checksum to detect and drop segments with bit-errors. Sequence numbers associated to data octets. Structure of submitted data stream not preserved. Urgent data service User can request immediate delivery of a subset of data in the byte stream (URG flag + pointer). Main functions Error control. Flow control. Congestion control. Octavian Catrina 16

17 Error control: Data acknowledgement User A TCP A TCP B User B ESTABLISHED ESTABLISHED Send(data[500]) Send(data[300]) Send(data[200]) Receive(data[400]) ACK, seq=s1, ack=s2, data[500] ACK, seq=s2, ack=s1+500 ACK, seq=s1+500, ack=s2, data[300] ACK, seq=s1+800, ack=s2, data[200] ACK, seq=s2, ack=s1+800 ACK, seq=s2, ack=s1+1000, data[400] ACK, seq=s1+1000, ack=s2+400 Receive(data[500]) Receive(data[300]) Send(data[400]) Receive(data[200]) Basic error control: cumulative acknowledgements and retransmission timer. The receiver returns an acknowledgement segment for every received data segment. The acknowledgement field indicates current in-order received data. Octavian Catrina 17

18 Error control: Sequence numbers Send sequence space Data sent, acknowledged Data sent, unacknowledged Data not sent SND.UNA SEG.ACK Receive sequence space Ack. sent, not received Data sent, not received SND.NXT SEG.SEQ RCV.NXT SEG.SEQ+SEG.LEN SEG.ACK Data received Data not received TCP segment header fields used for error control: Sequence number (SEG.SEQ) Acknowledgment number (SEG.ACK) Checksum. TCP state variables used for error control Send Sequence Variables SND.UNA - Send Unacknowledged SND.NXT - Send Next Receive Sequence Variables RCV.NXT - Receive Next Octavian Catrina 18

19 Basic data retransmission User A TCP A TCP B User B ESTABLISHED ESTABLISHED Send(data[500]) Send(data[300]) Send(data[200]) ACK, seq=s1, data[500] ACK, seq=s1+500, data[300] ACK, seq=s1+800, data[200] ACK, ack=s1 Store in buffer 500? 300 ACK, ack=s1 500? Timeout Retransmission of the data from s1 to s1+500 triggered by timeout ACK, seq=s1, data[500] ACK, ack=s Receive(data[1000]) Error control using cumulative acknowledgements and a retransmission timer. The receiver may save out-of-order data (beyond RCV.NXT) in its buffer to reduce retransmissions. Cumulative acks do not provide precise information about lost data. Inefficient, especially when multiple data segments are lost. Octavian Catrina 19

20 Dynamic timer adjustment TCP A TCP B Tdata[k], s1+500 seq=s1, data[500] RTT[k] = Tack[k]-Tdata[k] Tdata[k+1], s1+800 seq=s1+500, data[300] ACK, ack=s1+500 RTT[k+1] = Tack[k+1]-Tdata[k+1] Tack[k] ACK, ack=s1+800 Tack[k+1] Permanent round-trip time (RTT) measurements: RTT[k]. Computation of smoothed RTT: SRTT[k]. Computation of smoothed RTT deviation: SDEV[k]. New timer value: RTO[k] = SRTT[k] + 4 SDEV[k]. (Details in the annex) Octavian Catrina 20

21 Selective retransmission User A TCP A TCP B User B ESTABLISHED ESTABLISHED Send(data[500]) Send(data[300]) Send(data[200]) Retransmission of the data from s1 to s1+500 triggered by selective ack. Faster recovery ACK, seq=s1, data[500] ACK, seq=s1+500, data[300] ACK, seq=s1+800, data[200] ACK, ack=s1, sack=(s1+500 s1+800) ACK, ack=s1, sack=s1+500 s1+1000) ACK, seq=s1, data[500] ACK, ack=s Store in buffer 500? ? Receive(data[1000]) IF the SACK option is supported and enabled, the receiver uses selective acknowledgments to tell the sender what out-of-order data (beyond RCV.NXT) is saved in its buffer, and hence what data has to be retransmitted. Faster recovery, especially when multiple data segments are lost. Octavian Catrina 21

22 Example: Fast retransmission, no SACK HTTP data transfer over TCP connection from to without SACK. Fast retransmission: The sender retransmits after receiving > 3 duplicate acknowledgements. Data segment length: 1024 octets. Single lost packet. Lost data: seq [78354, 79378), 1 data segment Retransmission of lost data segment Lost data has been recovered Octavian Catrina 22

23 Selective acknowledgment (SACK) Cumulative acknowledgment: All data has been received up to sequence number Missing data from sequence number to (1024 octets) Selective acknowledgment option (SACK): Further data received from sequence number to Octavian Catrina 23

24 Example: Selective retransmission (1) HTTP data transfer over TCP connection from to with selective acknowledgements (SACK) Data segment length: 1024 octets. SLE: SACK Left Edge. SRE: SACK Right Edge. Single lost packet. Lost data: seq [162232, ), 1 data segment Retransmission of lost data segment All the lost data has now been recovered Octavian Catrina 24

25 Example: Selective retransmission (2) HTTP data transfer over TCP connection from to with selective acknowledgements (SACK) Data segment length: 1024 octets. SLE: SACK Left Edge. SRE: SACK Right Edge. Congested network path, multiple lost packets. Lost data, seq [40466, 43538) 3 data segments (congestion) Lost data, seq [45586, 46610) 1 data segment Retransmission of the 4 lost data segments All the lost data has now been recovered Octavian Catrina 25

26 Flow control Allows the receiver to slow down a faster transmitter End-to-end flow control using sliding-window mechanism. Flow control window Upper limit for the amount of data that a transmitter can send (beyond the acknowledged sequence). Explicitly indicated by the receiver. Sender Data (sequence number) Receiver, bottleneck. Update transmitter window ACK(acknowledgement number, window size) Indicate receiver window Octavian Catrina 26

27 Flow control: Sender/receiver windows Send sequence space Data sent, acknowledged Last advertised window (SND.WND SEG.WND) Consumed Data sent, unacknowledged Available Can be sent (sender window) Cannot be sent (out of window) SND.UNA SEG.ACK Ack. sent, not received Data sent, not received SND.NXT SEG.SEQ SND.UNA + SND.WND Receive sequence space Data received RCV.NXT SEG.ACK Can be received (receiver window) RCV.NXT + RCV.WND Cannot be received Advertised window size (RCV.WND SEG.WND) Octavian Catrina 27

28 Flow control: example User A TCP A TCP B User B ESTABLISHED Send(data[500]) Send(data[300]) Send(data[400]) Waiting for credit Stop Retrans Timer Start Persist Timer Stop Persist Timer ACK, seq=s1, data[500] ACK, seq=s1+500, data[300] ACK, seq=s1+800, data[200] ACK, ack=s1, wnd=1000 ACK, ack=s1+500, wnd=500 ACK, ack=s1+800, wnd=200 ACK, ack=s1+1000, wnd=0 ACK, ack=s1+1000,wnd=800 ACK, seq=s1+1000, data[200] ACK, ack=s1+1200,wnd=600 ESTABLISHED Receiver buffer Receive(data[800]) Octavian Catrina 28

29 Congestion control Limits transmission to avoid network congestion As congestion is building up, IP routers start dropping packets. Also, the transfer delay increases (due to queuing delay). TCP congestion control adjusts the transmission rate according to implicit congestion signals from the network. Assumes that packets are lost due to congestion rather than bit errors. Details in next section. LAN LAN IP network (bottleneck) Slow down TCP transmitter Dropped packets (detected by error control) Octavian Catrina 29

30 Graceful close User A TCP A TCP B User B ESTABLISHED ESTABLISHED Close FIN-WAIT-1 Closing stream AB FIN-WAIT-2 Stream AB closed Terminate TIME-WAIT Streams AB closed CLOSED FIN, ACK, seq=s1, ack=s2 ACK, seq=s2, ack=s1+1 FIN, ACK, seq=s2, ack=s1+1 ACK, seq=s1+1, ack=s2+1 Separate, independent closing of each of the two data streams. Complete data delivery guaranteed. Closing CLOSE-WAIT Stream AB closed Close LAST-ACK Closing stream BA Terminate CLOSED Streams AB closed TIME-WAIT state: wait twice the Maximum Segment Lifetime (MSL) before releasing the connection's state (e.g., 1-2 min.). Octavian Catrina 30

31 Closing: avoiding anomalies TIME-WAIT state Waiting time before releasing the connection's state after closing. Duration: 2MSL. Roles MSL = Maximum Segment Lifetime (e.g., 1-2 min.). Allow recovery of the last closing handshake. Prevent the reuse of the connection's address pair as long as its packets can survive Avoid interference between successive connection instances. Octavian Catrina 31

32 Congestion in IP networks Non-responsive Flows Octavian Catrina 32

33 Packet forwarding model R1 Limited packet queue (buffer) size R5 R3 Bottleneck link R4 R2 Packets dropped when the queue overflows R6 A router determines the interface on which a packet has to be sent out, and appends the packet to its queue. Packet queues allow routers to handle short term overload, i.e., received packet bursts exceeding the link bandwidth. In case of persistent overload (or large bursts), queues overflow, and packets are discarded. Octavian Catrina 33

34 Example: Congestion in IP networks R1 r1=10 r2=90 r=100 r=100 R3 r=20 r1=2 r2=18 R4 R5 r=10 r1=2 r=1 r2=1 Overall throughput: r1+r2 = 2+1 = 3 But we could get: r1+r2 = 10+1 = 11 R2 R6 How? Overload combined with waste of resources E.g., bottleneck links: insufficient bandwidth on links R3-R4-R6 for the red flow; overloaded link R3-R4 for the blue flow. R3 and R4 drop many packets, because the bandwidth of the links R3-R4 and R4-R6 is largely exceeded. The red flow throttles the blue flow: its packets consume a lot of bandwidth on R3-R4, and are dropped later at R4! Very inefficient and unfair operation Octavian Catrina 34

35 Delay Throughput Congestion Behavior under heavy load Knee: point after which throughput increases slowly. delay increases quickly. Cliff: point after which throughput decreases quickly to zero - congestion collapse. delay goes to infinity. Cause of congestion collapse Resources are consumed by useless packets, e.g., discarded later, repeated retransmissions. Congestion avoidance: stay at knee Congestion control: stay left of the cliff knee under utilization saturation Octavian Catrina 35 cliff Congestion collapse over utilization Load Load

36 Congestion experiments (1) H0 H1 r0 = 8 r1 = 8 BW0 = 100 Test 1: H0, H1 send at r0 = r1 = 8 (UDP) r0' 8 r1' 8 r3 = 16 BW1 = 100 R1 BW = 20 Bottleneck link N3 R2 N4 BW5 =10 BW6 =10 H5 H6 r5 = 8 r6 = 8 Data rates are measured at H0, H1, H5, H6 and on the bottleneck link. The color code is shown in the picture above. No congestion. No data lost. Network delivers r = 16 (up to 20). Flow H0 to H5 starts at 0. Flow H1 to H6 starts at 20. Measured throughput includes 20% encapsulation overhead! Octavian Catrina 36

37 Congestion experiments (2) H0 H1 r0 = 8 r1 = 80 BW0 = 100 Test 2: H1 sends at r1 = 80 (UDP) r0' 1.82 r1' r3 = 20 BW1 = 100 R1 BW = 20 Bottleneck link N3 R2 N4 BW5 =10 BW6 =10 H5 H6 r5 1.8 r6 10 Data rates are measured at H0, H1, H5, H6 and on the bottleneck link. Color code is shown in the picture above. Congestion: inefficient, unfair network utilization. - H1 sends at r=80 on path with BW=10. Only r=10 delivered. - H1 takes most of the BW on the bottleneck link. Almost nothing left for H0, almost all data lost. - Network delivers r 11.8, although r = 8+10 = 18 <20 is possible. Octavian Catrina 37

38 Congestion experiments (3) H0 H1 r0 = 8 r1 = 80 BW0 = 100 Test 3: H1 sends at r1 = 80 (UDP), BW6 = 1 r0' 1.82 r1' r3 = 20 BW1 = 100 R1 BW = 20 Bottleneck link N3 R2 N4 BW5 =10 BW6 =1 Bottleneck link H5 H6 r5 1.8 r6 1 Data rates are measured at H0, H1, H5, H6 and on the bottleneck link. Color code is shown in the picture. Congestion collapse: hardly anything delivered. - Network delivers r 2.8, although r = 8+1 = 9 < 11 is possible. Octavian Catrina 38

39 Congestion in IP networks TCP Congestion Control Octavian Catrina 39

40 IP and TCP congestion control IP network behavior When congestion builds up, the packets accumulate in routers' packet queues. The transfer delay increases, the routers start dropping packets. IP congestion control Routers use queue management mechanisms to control the queue size and decide which packets to forward or drop and when. TCP host behavior TCP monitors the amount of data in transit, the round-triptime, and the lost packets. It assumes that lost packets are congestion symptoms. TCP congestion control TCP limits its transmission using a congestion window, dynamically adjusted based on congestion symptoms. Goals Efficiency: Avoid overload (collapse) as well as underutilization. Fairness: Allocate a fair share of resources to all flows. Smooth convergence (low oscillations) to efficiency and fairness. Octavian Catrina 40

41 TCP data transfer (1/3) Transmission rate R' DATA Amount of data in the pipe: N = R D Data pipe with rate R and delay D The network path used by a TCP connection is (roughly) a data pipe with rate R and delay D The rate R is limited by the slowest link. The delay D is the sum of per hop transmission, propagation and queuing delays. Ideally, the source sends at rate R' R and, once the data pipe fills up, data flows at the maximum throughput. If the source sends faster, the pipe "leaks" and some data is lost (i.e., discarded by the routers). Problem: R and D are variable (depending on network traffic) and the TCP sender does not know them. Octavian Catrina 41

42 TCP data transfer (2/3) Transmission rate R' DATA Amount of data in the pipe: N = R D Data pipe with rate R and delay D ACK RTT (Round-Trip Time) seq=s1, data[1000] seq=s1+1000, data[1000] seq=s1+2000, data[1000] seq=s1+3000, data[1000] seq=s1+4000, data[1000] seq=s1+5000, data[1000] ACK, ack=s ACK, ack=s ACK, ack=s ACK, ack=s The TCP acknowledgment mechanism allows TCP to fill the pipe (handle multiple unacknowledged data segments), and to estimate the current RTT and the current amount of data in the pipe. Sent during RTT Unacknowledged = SND.NXT - SND.UNA. Octavian Catrina 42

43 TCP data transfer (3/3) DATA TCP sender: R =? D =? CWND R RTT R' CWND / RTT Transmission rate R' Amount of data in the pipe: N = R D Data pipe with rate R and delay D ACK TCP adjusts its transmission rate to the available data rate on the network path: Maintains a congestion window CWND which approximates RRTT. Limits transmission such that the amount of unacknowledged data (SND.NXT - SND.UNA) is less than CWND (also less than the window advertised by the receiver, for end-to-end flow control). Advances the window (and sends more data) when ACKs arrive, indicating that some data was delivered (hence exited the pipe). Therefore, ACKs also provide transmission timing (self-clocking). How to dynamically adjust CWND such that to satisfy the goals (efficiency, fairness, smooth convergence)? Octavian Catrina 43

44 ... Efficiency and fairness Source 1 Source 2 Source n x 1 x 2 x n Control system model x k Binary feedback: - decrease x k - increase x k increase: x k (t+1) = a I x k (t) + b I decrease: x k (t+1) = a D x k (t) + b D Goals This system converges to data rates meeting the efficiency and fairness goals only for additive or multiplicative increase and (x 1,x 2 ) multiplicative decrease. (a D x 1 +b I, Best: Additive Increase & Multiplicative Decrease (AIMD): Additive Increase: x k (t+1)=x k (t)+b I Multiplicative Decrease: x k (t+1)=a D x k (t) Basic solution used by TCP congestion control mechanisms (+ enhancements). a D x 2 +b I ) Flow 1, rate x 1 Octavian Catrina 44 Flow 2, rate x 2 Flow 2, rate x 2 Goals: Efficiency and fairness Example: 2 flows underutilization x 1 +x 2 C (a D x 1, a D x 2 ) x 2 > x 1 too much for x 2 x 1 > x 2 too much for x1 Flow 1, rate x 1 fairness line: x1=x2 overutilization x 1 +x 2 C efficiency line: x 1 +x 2 =C fairness line efficiency line

45 TCP congestion control Congestion window (CWND) adjustment At steady state, CWND oscillates around the current optimal value, CWND R RTT, for the throughput R that the network path can offer to the TCP flow, and the current RTT. congestion window Additive increase Multiplicative decrease time Basic algorithm components Additive increase: "Congestion avoidance. Multiplicative decrease: After detecting packet loss. "Slow Start : Gradual increase of CWND from 1 to SSTHRESH (slow start threshold) after connection setup and timeouts. Enhancements: "Fast Retransmit" and "Fast Recovery". Octavian Catrina 45

46 Slow Start, Congestion Avoidance (1/3) cwnd Slow Start (fast additive increase!) ssthresh Congestion Avoidance (slow additive increase) Timeout (multiplicative decrease) Slow Start ssthresh Congestion Avoidance time Slow start: if cwnd ssthresh - additive increase Increment cwnd by one segment for each (non-duplicate) received ACK. The congestion window starts from 1 segment and doubles every RTT. Congestion avoidance: if cwnd ssthresh - additive increase Increment cwnd by 1/cwnd for each (non-duplicate) ACK. The congestion window grows linearly, with one segment every RTT. Timeout (congestion symptom) - multiplicative decrease ssthresh max(sentunacked/2, 2segment); cwnd 1segment. Octavian Catrina 46

47 Slow Start, Congestion Avoidance (2/3) cwnd DATA... ACK Variation of the congestion window during Slow start and Congestion Avoidance cwnd slow start congestion avoidance ssthresh=8 round-trip times cwnd = congestion window (segments) ssthresh = slow-start threshold (segm.) (Simplified - see RFC 2581) Initially: cwnd = 1; ssthresh = large; Ack received (not a duplicate): // Additive increase if (cwnd < ssthresh) // Slow Start cwnd = cwnd + 1; else // Congestion Avoidance cwnd = cwnd + 1/cwnd; Timeout: // Multiplicative decrease ssthresh = SentUnacked/2; cwnd = 1; Octavian Catrina 47

48 Slow Start, Congestion Avoidance (3/3) cwnd ssthresh (initial) Slow Start (fast additive increase!) Timeout (multipl. decrease) Slow Start ssthresh Congestion Avoidance (slow additive increase) Timeout (multipl. decrease) Slow Start ssthresh Congestion Avoidance time Another scenario: timeout during slow start Note how ssthresh is adjusted after each timeout. ssthresh max(sentunacked/2, 2segment); cwnd 1segment. Octavian Catrina 48

49 Data retransmission seq=s1, data[1000] seq=s1, data[1000] seq=s1+1000, data[1000] seq=s1+1000, data[1000] seq=s1+2000, data[1000] seq=s1+3000, data[1000] ACK, ack=s1 ACK, ack=s1 seq=s1+2000, data[1000] seq=s1+3000, data[1000] ACK, ack=s1 ACK, ack=s1 ACK, ack=s1 2 duplicate ACKs ACK, ack=s1 Retransmission timer expires seq=s1, data[1000] Timeout retransmission ACK, ack=s seq=s1, data[1000] Could retransmit (?) ACK, ack=s RFC 2581 requires the reception of three duplicate ACKs before fast retransmission Timeout retransmission The timer is adjusted based on RTT measurements, but set to a conservative value (substantially larger than RTT). Duplicate ACKs When data arrives out of order due to the loss of previous segments, the receiver returns an ACK indicating the expected sequence number. Can be used to trigger earlier retransmission. Octavian Catrina 49

50 Fast Retransmit, Fast Recovery cwnd Fast retransmit TCP Tahoe cwnd Fast retrs.+ Fast recovery TCP Reno Slow Start Congestion Avoidance Slow Start Congestion Avoidance Slow Start Congestion Avoidance Congestion Avoidance time time Fast Retransmit Add another congestion symptom event: three duplicate ACKs. Faster than waiting for timeout. Introduced in TCP Tahoe. Fast Recovery Duplicate ACKs are received The network still delivers data Light congestion Do not empty the pipe, just reduce the amount of data to half. Set CWND=ssthresh=SentUnacked/2. See details in RFC 2581 and RFC Added in TCP Reno. Octavian Catrina 50

51 Analysis TCP transmission rate R k L/(T q 1/2 ) (bps) L = packet length; T = round-trip-time. q = packet loss rate; k = (3/2) 1/ Approximation of the TCP behavior congestion window W W/2 time T 0 2T 0 Limitations of TCP congestion control mechanisms Vulnerable to non-congestion related loss (e.g., wireless). Flows with very long RTT are penalized (lower throughput). All sources must cooperate. Otherwise, the sources that respond to congestion are locked out by the sources that do not. TCP friendly applications Some applications do not use TCP (e.g., voice/video). IETF solution: Applications must be "TCP friendly", i.e., use an adaptive transmission algorithm with the same data rate as a TCP connection experiencing the same packet loss. Octavian Catrina 51

52 Simulation setup Traffic sources TCP or UDP (CBR) Traffic sinks TCP or UDP Monitor queue size Monitor link throughput Monitor TCP cwnd,... R1 Bottleneck link Trace packets dropped when the queue overflows Queue management: FIFO, Tail-drop R2 Monitor end-to-end throughput Octavian Catrina 52

53 TCP Tahoe Bottleneck link TCP R1 queue size (capacity: 5000) ssthresh Slow Start Congestion Avoidance Octavian Catrina 53

54 TCP Reno Bottleneck link TCP R1 queue size (capacity: 5000) ssthresh Slow Start Congestion Avoidance Fast Recovery Octavian Catrina 54

55 TCP (Reno) + UDP/CBR Link TCP; TCP; CBR CBR start: 80 R1 queue size (<= 5000) Octavian Catrina 55