Internet Transport Protocols UDP and TCP

Transcription

1 Outline Internet Transport Protocols UDP and TCP Transport Layer Review UDP Protocol UDP Characteristics UDP Functionalities TCP Protocol TCP Characteristics Connection Management TCP Flow and Congestion Control Design Issues TRANSPORT LAYER Transport Layer Services and Protocols Transport layer provides a logical connection between application processes running on different hosts Transport Layer Services Connection Management If connection-oriented Multiplexing and De-Multiplexing Data Segmentation and Reassembly Error, Flow and Congestion Control 1

2 Transport Layer Concepts Host Application Transport IP Network Access Physical Internet Logical Connection Router NA PHY IP NA PHY Host Application Transport IP Network Access Physical Internet Internet Transport Layer Protocols The IP suite offers two transport protocols User Datagram Protocol (UDP Connectionless protocol Best Effort Service Unreliable Unordered datagram delivery No error or flow control Transmission Control Protocol Connection-oriented protocol Reliable, ordered delivery of byte stream Error, flow and congestion control No delay guarantees and no bandwidth guarantees User Datagram Protocol UDP UDP Characteristics UDP is a connectionless datagram service. No need to establish a connection prior to data transfer Datagrams may be generated and transmitted at any time. UDP datagrams are self-contained. UDP is unreliable: No acknowledgements for reliable delivery of data. Checksums cover the header, and only optionally cover the data. Contains no mechanism to detect missing or out of sequence datagrams. No mechanism for automatic retransmission. No mechanism for flow control Sender can over-run the receiver. 2

3 UDP Service UDP provides unreliable connectionless delivery service using IP to transport datagrams UDP does not enhance the best effort service provided by IP UDP provides a mechanism to distinguish among multiple destinations within a host The mechanism, referred to as multiplexing, is based on the notion of ports IP Communication Ports To communicate, a sender needs to know IP address of the remote host and Port number within that host Multiplexing in UDP UDP Operation Port 1 Port 2 Port 3 Port 1 Port 2 Port 3 Port 4 A1 A2 B1 B2 UDP Module TCP Module App App App App RARP Module IP Module ARP Module OS UDP Network Interface Frame IP address, Protocol, Port number IP UDP uses port number to de-multiplex packets 3

4 User Datagram Protocol UDP Checksum Physical Header UDP Source Port UDP Message Length Data IP Datagram Physical Data Frame UDP Destination Port UDP Checksum IP Header UDP Header Data Physical Trailer UDP source port is optional (set to 0 if not used) UDP checksum is optional (set to 0 if not used) Using UDP checksum option is useful, however, since IP checksum does not cover the data portion of the datagram It provides the only way to ensure that data has arrived intact and should be used Also, the only way to verify the UDP header UDP Checksum Appropriate Uses of UDP The UDP checksum covers more information than is present in the UDP datagram A pseudo-header is prepended to the UDP datagram, and a checksum over the entire object is computed The pseudo-header contains source and destination IP addresses, IP protocol type (code 17 for UDP), and UDP datagram length (the pseudo-header not included) It guarantees that the datagram has reached the proper destination The checksum is computed as a one s complement sum (sum modulo ) of all 16-bit words of the header and the pseudo-header (checksum field is set to 0) and taking one s complement of the result Inward data collection Outward data dissemination Request-response Real-time applications Streaming of real-time audio and video. On-time delivery is important Minimum overhead 4

5 Transmission Control Protocol TCP Transmission Control Protocol TCP provides a reliable virtual circuit service TCP guarantees ordered delivery of a stream of data without loss or duplicatio, despite unreliable network packet delivery service TCP assumes little about the underlying communication system TCP can be used with a variety of packet delivery services Dial-up telephone lines Local and wide area networks Low and high-speed long haul networks TCP Interface Characteristics Virtual Circuit connection TCP is full-duplex TCP is stream-oriented protocol Data is viewed as a stream of bytes TCP provides an unstructured stream TCP does not mark boundaries between streams Application s responsibility to understand stream contents Buffered transfer TCP collects enough data to fill a reasonably large datagram before transmission TCP provides a push mechanism to force transfer, if needed TCP supports a stream of bytes service Sender Receiver 5

6 Stream Service is emulated using TCP Segments Sender Receiver TCP Data TCP Data Segment sent when: Segment is full MSS bytes, Segment not full, but times out, or Pushed by application. MSS = Maximum Segment Size TCP MSS TCP segments are the messages that carry data between TCP sender and receiver TCP must decide how many bytes to put into each message that it sends. The current size of a TCP segment, CSS, is determined by two factors The size of the receiver s window (bytes) W A ceiling on TCP size segment size, never to be exceeded Maximum Segment Size (MSS) CSS = minimum(mss, W) TCP Interface Characteristics TCP specifications describe generally how applications use TCP, but do not dictate details of an interface There have been numerous implementations of TCP TCP Reno, TCP Tahoe, TCP Las Vegas, SACK TCP,. TCP Connection Establishment Initially, a service user at site 1 issues a passive open function Willingness to accept connections from other users TCP returns a passive open confirm with local connection name to use when a connection is set up Service user at site 1 can start listening for requests 6

7 TCP Connection Establishment Three-way Handshake To establish a connection with service at site 1, a user at side 2 issues an active open Active open contains data needed to set up the connection This begins a three-way handshake Send data unit with SYN bit set and seq# = x Receive data unit SYN x ACK x+1/syn y Receive data unit Send data unit with SYN bit set and seq# = y, acknowledge x+1 Send data unit acknowledge y+1 ACK y+1 Receive data unit Connection Termination Connection Termination TCP connections are terminated with graceful close Graceful close ensures that the connection is terminated after all data had been received One side issues Close request, and is not permitted to transmit data after sending it The other side acknowledges it, but can send data until it sends Close request too After the second Close request is acknowledged, the connection is closed No data transmission from this side FIN x ACK x+1/ Data y ACK y+k+1 FIN y+k ACK y+k+1 Last segment sent by receiver Sequence number : y Length: k 7

8 TCP Segment Format TCP Segment Fields Data Offset Source Port Reserved Sequence Number Acknowledgement Number U R G Checksum A C K P S H R S T Options S Y N F I N Data Destination Port Window Urgent pointer Padding Source and Destination Port Number 16-bit end-point identifiers Sequence Number 32-bit number of the first data octet in this segment except for when the SYN flag is set When the SYN flag is set, sequence number identifies the Initial Sequence Number and the first data octet is ISN+1 Acknowledgement Number 32-bit number of the next octet expected to receive Data Offset 4-bit number of 32-bit words in the header (including options) Header Length TCP Flags URG: segment contains urgent data: urgent pointer points to the last octet of urgent data ACK: acknowledgement field is significant PSH: segment is sent with the push function RST: reset the connection Closes a half-open connection SYN: synchronize sequence numbers Used during open request FIN: no more data from sender Used during close request TCP Segment Fields Window 16-bit number of unacknowledged octets that the sender is allowed to transmit Maximum value limits the value of the window size to 216, unless window scale option is used Checksum 16-bit one s complement of a one s complement sum of all 16-bit words of the segment and a pseudo-header (the checksum field is set to zero) The pseudo-header contains the sender s and receiver s IP addresses, the protocol type (code 6 for TCP), and the segment length field) A zero padding is added to the segment to make the segment multiple of 16 bits The pseudo-header and the padding are not transmitted 8

9 Pseudo-header Out-of-Band Data Source address (32-bits) Destination address (32-bits) Protocol TCP segment length Out-of-band data is needed to handle abort or program interrupt signals These signals should not wait for the octets already in the TCP stream to be transmitted Telnet uses this feature to send interrupt commands TCP uses URGENT feature to accomodate out-of-band data Out-of-Band Data Out-of-Band Data User Process Out-of-Band Data Send Buffer Network Out-of-Band Data Receive Buffer Application is required to check on the Out-of-Band data stream before processing regular data stream User Process TCP notifies associated application of the beginning and end of urgent mode How TCP informs the application depends on the operation system Urgent data is detected by the URG flag set and retrieved by the urgent pointer Unfortunately, TCP does not denote the beginning of the urgent data in the segment It s up to the application to decide, where the urgent data starts 9

10 TCP Options Originally, one option, maximum segment size was defined The 16-bit option may be used only in the initial connection request segment If this option is not used, any segment size is allowed Later, two other options have gained widespread acceptance Window scale factor Timestamps TCP Options End of options Kind = 0 (8 bits) No operation : padding Kind = 1 (8 bits) TCP Options Maximum Segment Size Window Scale Option Purpose Kind = 2 (8 bits) Length = 4 (8 bits) Maximum Segment Size (16 bits) Window Scale Factor Kind = 3 (8 bits) Length = 3 (8 bits) Shift Count (8 bits) 10

11 Window Scale Option The option increases the TCP receive window above its maximum value of 65,535 bytes A much better alternative than changing the TCP header to accomodate the need for larger windows When window scale option is used, the value of the field is multiplied by 2 F, where F is between 1 and 14, is a scale option specified in the initial connection request segment A value F = 14 results in a maximum window size of over 10 9 bytes ( ) Internally, TCP maintains a real window size of 32 bits The option can only appear in a SYN segment Thus, scale factor is agreed upon and fixed in each direction at the connection setup TCP Options Timestamp Used for 2 distinct mechanisms RTT Measurement (RTTM) To track the RTT for data in order to identify changes in latency that may require ack timer adjustment Protect Against Wrapped Sequences (PWAS) Kind = 8 (8 bits) Length = 10 (8 bits) Timestamp Value (LSB) (16 bits) Timestamp Echo Reply (LSB) (16 bits) Timestamp Value (MSB) (16 bits) Timestamp Echo Reply (MSB) (16 bits) This option can be used throughout the TCP connection TCP FLOW CONTROL TCP Data Flow Control TCP uses a variable size window protocol to regulate the flow control Its unique feature is that it decouples acknowledgements of received data units from the granting of a permission to send additional data Each acknowledgement contains a window advertisement Increased window advertisement allows sender to proceed with sending octets not acknowledged yet Decreased window advertisement causes the sender to stop at the boundary of the window 11

12 TCP Sliding Window Data AcK d Window Size Outstanding Un-Ack d data Data OK to send Data not OK to send yet Window is meaningful to the sender Current window size is advertised by receiver Usually 4k 8k Bytes when connection set-up Acknowledgements and Retransmission TCP uses a cumulative acknowledgement scheme ACK reports on the number of octets so far accumulated and specifies the next octet expected Advantages ACKs are easy to generate unambiguously Lost ACKs do not necessarily force a retransmission Disadvantages Receiver does not report on the segments successfully received, if one intermediate segment is lost Timeout mechanism becomes very crucial TCP Window Mechanisms TCP uses a credit allocation scheme The sender includes the sequence number of the first octet in the segment data field The receiver acknowledges the incoming segment with a message of the form (ACK = i, WIN = j ) All octets up to i-1 are acknowledged Permission is granted to send an additional window of j octets starting at i through i+j-1 TCP Credit Allocation Scheme The credit allocation scheme is flexible Assume last message issued by receiver carries ACK = i and WIN = j To increase the credit by an amount k > j, when no additional data have arrived, the receiver issues ACK = i and WIN = k To acknowledge an incoming segment containing m octets of data (m < j) without granting additional credits, the receiver issues ACK = i+m and WIN = j-m The receiver can issue cumulative acks, and is not required to issue an ack immediately after receiving a segment 12

13 TCP Window Control Effect of Window Size Sender Receiver SN LEN ACK WIN ACK WIN TCP Actual Throughput TCP performance can be affected by several complicating factors: In most cases, a number of TCP connections are multiplexed over the same network interface, so each connection is only allocated a fraction of bandwidth This reduces R, therefore S as well TCP connections usually involve a hop across multiple networks Router delay becomes the biggest contributor to D Actual data rate may be reduced below R if a bottleneck router exists along the path If any segment is lost and must be retransmitted, throughput is reduced TCP Sliding Window Fundamental Questions How much data can a TCP sender have outstanding in the network? How much data should TCP retransmit when an error occurs? Just selectively repeat the missing data? How does the TCP sender avoid overrunning the receiver s buffers? 13

14 TCP Flow Control TCP Flow Control Receiver throttles sender by advertising a window size no larger than the amount of data it can buffer. To avoid buffer overflow at the receiver side, the following invariant is always true: LastByteRcvd - LastByteRead <= MaxRcvBuffer TCP receiver advertises the following window: AdvertisedWindow = MaxRcvBuffer - (LastByteRcvd - LastByteRead) It is the amount of free space available in the receiver s buffer. TCP Flow Control Window The TCP sender must adhere to AdvertisedWindow from the receiver such that: LastByteSent LastByteAcked <= AdvertisedWindow This defines an Effective Window: TCP Flow Control Sender Flow Control Rules: The EffectiveWindow must be > 0 for sender to send more data. LastByteWritten LastByteAcked <= MaxSendBuffer When equality is reached send buffer is full!! TCP sender must block the sending application. EffectiveWindow = AdvertisedWindow (LastByteSent - LastByteAcked) 14

15 TCP Congestion Control TCP CONGESTION CONTROL TCP sliding window provides an adequate mechanism to control the data flow between the sender and the receiver TCP sender still needs to perform congestion control to ensure that the network can handle the window agreed upon by the sender and the receiver TCP relies on ACKs to control flow and congestion If the ACK is not received on time, TCP retransmits the segment An absence of an ACK signals congestion in the network TCP Window Control TCP Timeout Timers TCP does not rely on an explicit negative acknowledgement to detect errors TCP relies exclusively on positive ACKs and retransmissions when an ACK does not arrive within a given period of time Retransmission TimeOut (RTO) should be on the order of RTT (Round-Trip Time) RTT and its statistics, however, vary considerably as the Internet load changes Thus timers play a major role in TCP congestion Sender Receiver Data Round-trip time (RTT) ACK Data Retransmission TimeOut (RTO) ACK Guard Band Estimated RTT 15

16 Timer Values The timeout timer should be set to a value somewhat longer than the RTT Two strategies can be used to set the timer value: Static timer value Adaptive timer value Static Value Timers A fixed value timer based on the Internet typical behavior is used for RTO value The strategy suffers from the inability to respond to Internet changing conditions A high value leads to sluggish service and unnecessary long time of response to a lost packet A low value leads to a positive feedback condition that causes more retransmissions (some unnecessary) in a case of congestion Adaptive Timers TCP keeps track of the time taken to acknowledge data segments and sets its retransmission timers based on the average of the observed delays Can this be trusted? Cumulative ACK by the peer may delay an acknowledgement If a segment has been retransmitted, the sender cannot determine which segment (the original or the retransmitted), the ACK does correspond to Internet laod may change suddenly Still, tracks better RTT variation than the fixed strategy Adaptive Timers Smoothed Average An estimated value of RTT, SRTT(), is computed as a smoothed average SRTT k 1 SRTT k 1 RTT k 1 The smaller the value of, the greater weight of more recent observations With small values of, the average quickly reflects a rapid change in the observed quantity A disadvantage, a brief surge in the observed value followed by a return to the average causes strong fluctuations = 0.9 is recommended 16

17 Adaptive Timers Adaptive Timers Given an SRTT value, what should be the RTO value? Use a constant value: RTO k 1 SRTTk 1 is not proportional to SRTT If SRTT(k+1) is large, may become insignificant, relatively As a consequence, fluctuations in the RTT cause unnecessary retransmissions If SRTT(k+1) value is small, may become relatively large As a consequence, the mechanism depends solely on value, not reacting to changing conditions TCP Congestion Control TCP Congestion Control The rate at which a TCP entity can send data is determined by the rate of incoming ACKs to previous segments (with granted credit) This rate is determined by the bottleneck in the round trip path between the source and the destination Congestion control in the Internet is complex IP is a connectionless, stateless protocol No provision for determining congestion, let alone control it TCP provides only end-to-end flow control and relies on implicit feedback to deduce the presence of congestion ICMP quench messages are too crude to provide any effective control No cooperative, distributed algorithm exists between different TCP entities On the contrary, TCP entities may be selfish and do not cooperate to maintain some level of control 17

18 TCP Congestion Control The only tool is the sliding-window flow control and error control mechanisms Not enough, in a dynamic environment A number of clever techniques have been developed and added to control congestion in the Internet Mechanisms for congestion detection Mechanisms for congestion avoidance Mechanisms for congestion recovery TCP Flow and Congestion Control TCP is self-clocking: returning of ACKs functions as pacing signal After an initial burst, the sender s segment rate matches the arrival rate of ACKs Sender rate equals the rate of the slowest link on the path This way TCP senses the bottleneck and regulates its rate accordingly TCP Flow and Congestion Control Network Bottleneck Pb is the minimum segment spacing on the slowest link Pr is the segment spacing at the receiver As is the ACK spacing at the sender Ab is the ACK spacing at the bottleneck Pr Pb Data Pb = Pr = Ab = As TCP Flow and Congestion Control Problem caused by the fact that the sender does not know where is the bottleneck: the network or the receiver If ACKs arrive relatively slow due to network congestion, then the sender must transmit segments at a rate slower than the ACKs On the other hand, if slow pace is due to the receiver, this pace should dictate the transmission policy Thus, TCP sliding window must be enhanced to factor in the network congestion ACK As Ab 18

19 Probability Average Queueing Delay Improving TCP Congestion Effectiveness Three techniques have been suggested for retransmission timer management RTT Variance Estimation Exponential Backoff Karn s Algorithm Four techniques have been suggested for window management Slow Start Dynamic Window Sizing on Congestion Fast Retransmission Fast Recovery RTT Variance Estimation Factors of Influence RTT exhibits relatively high variance due to three sources A low data rate on the TCP connection relative to the progation time makes the transmission delay relatively important in the RTT estimation Thus, high variation in datagram sizes induces high variation in RTT SRTT estimator can be heavily influenced by characteristics of the data, that have nothing to do with the network Abrupt changes in the Internet load and condition TCP receiver may use cumulative ACKs RTO Scheme Revisited TCP Timeout Estimates TCP original scheme suggests to compute RTO as follows RTO k 1 SRTTk 1 ; 2 There will be some (unknown) distribution of RTTs. We are trying to estimate an RTO to minimize the probability of a false timeout. Router queues grow when there is more traffic, until they become unstable. As load grows, variance of delay grows rapidly. If RTT has low variance, it results in unnecessary high values of RTO In unstable environments, it may be inadequate to protect against retransmissions variance mean RTT Variance grows rapidly with load Load (Amount of traffic arriving to router) 19

20 RTT Variance Estimates A more effective approach is to estimate RTT standard deviation However, too costly as it involves square and square root calculation A less expensive alternative: the mean deviation MDEV X E X E X Dynamic Estimate of RTT Variability The algorithm to dynamically estimate the variability in estimating RTT uses an exponential smoothing technique SRTT k 1 SRTT k 1 RTT k 1 SERR k 1 RTT k 1 SRTT k 1 SDEV k 1 ' SDEV k 1 ' SERR k 1 RTOk 1 SRTT k 1 SDEV k 1 7 ; 8 ' 3 ; 4 4 TCP Congestion Control RTT variance estimation is efficient in detecting data loss It may not be sufficient in a case of retransmission Two other factors must be taken into consideration when managing retransmission timers in a case of congestion: What RTO value should be used on a retransmitted segment (i.e., when timeout occurs)? Exponential RTO Backoff What RTT samples should be used as input to compute SRTTT( ) in a case of retransmission? Karn s Algorithm Exponential RTO Backoff Timeouts are usually due to congestion Maintaining the same RTO value for retransmission is ill advised May cause sustained congestion due to the development of a similar pattern of behavior of all active TCP connections All sources wait for local RTO time and retransmit again A more efficient scheme must try to increase RTO values to give the Internet more time to clear the congestion Exponential RTO Backoff scheme RTO = q RTO Typically q = 2 20

21 RTT Samples Ambiguity Ambiguity may occur when a timeout occurs and the same segment is retransmitted Upon receiving an ACK, the sender has no way of determining which segment, the first or the second, has been acknowledged Feeding the resulting RTT into the RTO algorithm may lead to false measurements and oscilations Retransmission and Timeouts TCP Source cannot distinguish between these two cases Wrong RTT Sample Host A Retransmission Host B Wrong RTT Sample Host A Retransmission How can we estimate RTT when packets are retransmitted? Host B RTT Samples Karn s Algorithm Karn s algorithm uses the following rules Do NOT use the measured RTT for a retransmitted segment to update SRTT and SDEV Calculate the backoff RTO when a retransmission occurs RTO = q RTO ; (typically q = 2) Use the backoff RTO value for succeeding segment until an acknowledgement arrives for a segment that has not been retransmitted When the acknowledgement is received to an unretransmitted segment, use the normal algorithm to update SRTT and SDEV and compute future RTO values TCP Congestion Control Armed with an efficient RTO estimation mechanism, use lack of acknowledgements as congestion indication and maintain a congestion window to estimate congestion in the network CongestionWindow :: a variable maintained by the TCP source for each connection. TCP is modified such that the maximum number of bytes of unacknowledged data allowed is the minimum of CongestionWindow and AdvertisedWindow AllowedWindow :: Min (CongestionWindow, AdvertisedWindow) 21

22 Window Management Techniques A number of strategies have been suggested to effectively manage the sending window Slow Start Dynamic Window Sizing on Congestion Fast Retransmission Fast Recovery These techniques are incorporated in all modern implementations of TCP Slow Start TCP is self-clocking and paces itself approximately to the rate of the bottleneck At the initialization phase, no such pacing is available for guidance Sending at full window speed is ill-advised as it may cause large packet drops Some means of gradually expanding the initial window until pacing takes over is needed Slow Start is the procedure recommended for initial window expansion until packing takes over Phases of Congestion Control TCP Slow Start The goal of TCP Slow Start is to discover roughly the proper sending rate quickly Whenever starting traffic on a new connection, or whenever increasing traffic after congestion was experienced: Intialize cwnd =1 Each time a segment is acknowledged, increment cwnd by one (cwnd++). Continue until The threshold, ss_thresh, is reached or Packet Loss The variable ssthresh can be thought of as an estimate of the level below which congestion is not expected. 22

23 TCP Slow Start Dynamic Window Sizing on Congestion Each ACK adds 2 credits This gives the sender the permission to send two segments Slow start increases rate exponentially fast Rate is doubled every RTT! cwnd = 1 cwnd = 2 cwnd = 4 cwnd = 8 Slow Start enables the sender to quickly determine a reasonable window size for the connection What happens if packet loss (timeout) occurs? This could be a sign of congestion, but it is not clear how serious the congestion is Would resetting cwnd = 1 and restarting slow-start be enough? This may not be conservative enough Need a more aggressive response Congestion Avoidance: Additive Increase After exiting slow start, slowly increase cwnd to probe for additional available bandwidth Competing flows may end transmission May have been unlucky with an early drop If cwnd > ss_thresh then each time a segment is acknowledged increment cwnd by 1/cwnd (cwnd += 1/cwnd). cwnd is increased by one only if all segments have been acknowledged Increases by 1 per RTT, vs. doubling per RTT Congestion Avoidance: Additive Increase When a timeout occurs, use these rules: Set a slow-start threshold, ssthresh, equal to half of cwnd ssthresh = cwnd / 2 Set cwnd = 1 and perform slow start until cwnd = ssthresh At that time, cwnd is increased only by 1, for every ACK received For cwnd ssthresh, increase cwnd by 1 for each RTT 91 23

24 Cwnd (in segments) Example of Slow Start + Congestion Avoidance cwnd = 1 Assume that ss_thresh = ssthresh t=0 t=2 t=4 Roundtrip times t=6 cwnd = 2 cwnd = 4 cwnd = 8 cwnd = 9 cwnd = 10 TCP Improvement FAST RETRANSMIT FAST RECOVERY Acknowledgments in TCP Fast Retransmission Policy TCP Tahoe Receiver sends ACK to sender ACK is used for flow control, error control, and congestion control ACK number sent is the next sequence number expected Delayed ACK: TCP receiver normally delays transmission of an ACK (for about 200ms) Why? ACKs are not delayed when packets are received out of sequence Why? 1K SeqNo=0 AckNo=1024 1K SeqNo=1024 AckNo=2048 1K SeqNo=2048 1K SeqNo=3072 AckNo=2048 Lost segment When a segment is lost, original TCP waits for an ACK that s not coming and eventually times-out. It is often the case that of the segments sent after the lost segment arrive at the receiver. For each segment received, the receiver sends a duplicate ACK, notifying the sender that the receiver is waiting for the missing segment. TCP Tahoe interprets duplicate ACK s as an indication that a segment was lost

25 Fast Retransmit Fast Recovery cwnd=12 sshtresh=5 1K SeqNo=0 1K SeqNo=0 If three or more duplicate ACKs are received in a row, the TCP sender considers the segment as lost. Then TCP performs a retransmission of the missing segment, without waiting for a timeout to happen. duplicate duplicate AckNo=1024 AckNo=1024 AckNo=1024 1K SeqNo=1024 1K SeqNo=2048 1K SeqNo=3072 1K SeqNo=1024 Fast recovery avoids slow start after a fast retransmit Intuition: Duplicate ACKs indicate that data is getting through After three duplicate ACKs set: Retransmit lost packet ssthresh = cwnd/2 cwnd = cwnd+3 Enter congestion avoidance Increment cwnd by one for each additional duplicate ACK cwnd=12 sshtresh=5 cwnd=12 sshtresh=5 cwnd=12 sshtresh=5 AckNo=1024 AckNo=1024 AckNo=1024 1K SeqNo=1024 1K SeqNo=2048 1K SeqNo=3072 1K SeqNo=1024 1K SeqNo=4096 Enter slow start: ssthresh = cwnd/2 cwnd = 1 1K SeqNo=4096 When ACK arrives that acknowledges new data (here: AckNo=2028), set: cwnd=ssthresh enter congestion avoidance cwnd=9 sshtresh=9 AckNo= Fast Recovery Summary of TCP Behavior cwnd (initial) ssthresh fast-retransmit fast-retransmit new ACK new ACK Slow Start Congestion Avoidance timeout Time TCP Variation Tahoe Reno NewReno Response to 3 dupack s Do fast retransmit, enter slow start Do fast retransmit, enter fast recovery Do fast retransmit, enter modified fast recovery When entering slow start, if connection is new, ssthresh = arbitrarily large value cwnd = 1. else, ssthresh = max(flight size/2, 2*MSS) cwnd = 1. In slow start ++cwnd on new ACK Response to Partial ACK of Fast Retransmission ++cwnd Exit fast recovery, deflate window, enter congestion avoidance Fast retransmit and deflate window remain in modified fast recovery Response to full ACK of Fast Retransmission ++cwnd Exit fast recovery, deflate window, enter congestion avoidance Exit modified fast recovery, deflate window, enter congestion avoidance When entering either fast recovery or modified fast recovery, ssthresh = max(flight size/2, 2*MSS) cwnd = ssthresh. In congestion avoidance cwnd += 1*MSS per RTT 25

26 Summary Transmission Control Protocol Discussion Segment format and functionality TCP Flow Control TCP Congestion Control AIMD strategy 26